I'd like you to help me plan (brainstorm) a rebase of the current branch onto the trunk (master) to produce a logical sequence of commits adhering to the following rules (by splitting, merging & editing commits)
- Fixes for issues that are pre-existing on the trunk should be in separate commits and should typically come first
- Refactorings or architecture improvements that enable/facilitate a feature should be separate from the feature itself, if the improvement is something we'd want to keep even without the feature (i.e. it's generally beneficial)
- If a feature can be broken down into multiple sub-features (and those sub features make sense in isolation) then those sub-features should generally be separate commits. "It doesn't make sense to ship half a car, but we can ship a car with no air conditioning or stereo".
- We do not want "fixup" commits - while we cannot change things on the base (trunk) branch (it's immutable history) the history on the feature branch is mutable. So any fixups should be c