Adding an upper byte to stack pointer is trivial and seamless, consumes close to nil silicon area, and by no means violates the '51-ness
OH,
what happens to mov sp,#44. what happens to PUSH/POP speed, not to mention what happens to mov r1,sp - mov a,@r1? the "does it or doesn't it" would be a major buttpain for any compiler.

Similarly, it is rather trivial and seamless to add an upper byte to R0 and R1 (in all 4 banks), extending them to 16-bit pointers for all @Ri operations (including on internal memory locations).
Changing R0, R1 would be a buttpain for the compilers (does this derivative have it or not) since it can not be ignored. The multiple DPTRs _ which are SFRs - that some drivatives have can be ignored and "advanced" compilers can have an option of using them.

and have minimum impact on silicon area/cost, system complexity and use of existing and proven development tools.
All you have mentioned will have more than "minimum impact" on development tools, unless, of course, the tools leave the derivatives we know and love behind.

as far as "improving the chip" I love the fact that any chip designer can invent SFRs and add them. Some of the added SFRs available are quite "exotic" such as the 16 bit MAC in some of the SILabs f12x chips and the hardware digital filter in the BB/TI chip (I use neither, but see them as excellent examples of "improving the '51").

I am, however, not "sympathetic" towards any changes in the non_SFR areas of the chip, to open for changes there will be a pandoras box.

Erik