CentralAuth is large, hard to maintain, and extremely specific to Wikimedia wikis, even though many of its pieces aren't. Splitting it up into smaller extensions would have several advantages:

• better maintainability (e.g. many of these extensions would be very simple to install, while the current extension aren't)
• clearer scope (e.g. different WMF teams would want to make decisions about authentication techniques vs. anti-abuse features)
• reusability (while the concept of merging users with the same name on different wikis is fairly WMF-specific, global permissions or global rename are very generic and could easily be reused with different authentication extensions)

This has been discussed at many places (e.g. User:Taavi/CentralAuth, T252244#6339170, T358979#9596007) and I think there is more or less a silent consensus that this should be the long-term trajectory of the extension, so let's try to turn that that into an explicit consensus.

Usually the fragments proposed look something like this:

• The central user database stays in CentralAuth and becomes the single purpose of the extension. (Possibly better integrated into core via something like T352823, but it's not necessary.) It continues to handle login and registration, the globaluserinfo and globalallusers APIs, and related complications with SUL migration phases (or maybe that gets dropped per T288906).
• The central session and the centralauthtoken API (ie. the SSO functionality) becomes a new extension.
• Global groups and wikisets become a new extension. T355381: Split global group and wiki set to a new extension
• Global account suppression and locking can go into GlobalBlocking (with locking maybe converted into regular blocks). T17294: Allow blocking of global accounts (and various related tasks)
• Global rename becomes its own extension. T343984: Split global rename requests/queue to a separate extension
• Find a home for the various smaller bits like global password policies, global edit count, Special:CentralAuth.

The glue between the various extensions would be the CentralIdLookup service in core; plus in a few cases an explicit assumption that the same user is called the same name over various wikis (global rename at least wouldn't really make sense without that assumption).