In the past, we've tackled with the idea of splitting core several times; Core has grown to 800+ classes and has many test classes. As such, it is becoming increasingly difficult to package, test, and design features new and old. Some fairly old code is barely used anymore; most code is stable, but would benefit from better packaging and design. The first targets will be things that have no dependencies on our own APIs, e.g JCR Utilities (predicates, wrappers, etc). Other example cases would be content-i18n, security, virtual URIs, etc.
Isolating features in smaller modules would help incrementally refactoring, rewriting or throwing code away.
In the future, some of those splitted out modules could even move out of magnolia_main, because they'll be very stable and have different lifecycles (JCR Utilities, for example)
With this and some modules being splitted out of magnolia_ui, we might even be able to "merge" main and ui into what it really: Magnolia Platform (smile)
After some initial tests, what was a 3-step gradual implementation of the above is now a 4-step one. We added step #1 to the original proposal. We'd do this in 4 steps to give margin to users (and ourselves) to upgrade their dependencies. Ideally with Step #1 no change is needed for people who already use scope:import for magnolia-project or one of our webapps.

See https://wiki.magnolia-cms.com/display/DEV/Core+split