There might be a small niche for such a part but I don't see that an 8051-ARM transition part would be all that useful.

First, as an update to an existing design the basic limit would still be the peripherals on the board. An ARM core would add memory and speed, but if an 8051 was sufficient for the initial design then there isn't much room for improvements with a faster CPU. After all, the hardware was oriented toward 8051 capabilities; if there's no need for 32 bit arithmetic then it's a not going to be a compelling reason to change.

For a new design such a part would be next to useless. A highly integrated ARM (I use ST part like STR750 and STM32) doesn't have any 8051 versions competing with it. There's no compelling reason to use an 8051 footprint when I need 100 or 144 pins on the controller. And if the application only requires the small pin count/peripherals of an 8051, then I'd still use an 8051.

Second, software costs are what usually justifies my design choice of an ARM over an 8051. I still use a lot of 8051s, SiLabs parts, but there's a clear cutoff where the software costs dictate a switch to ARM.

One of the biggest advantages I have found with using ARM controllers is the speed and code space to design better program workflows. I use an RTOS to run multiple tasks on ARMs, a clean way to separate application requirements. On an 8051 I have to use an event loop combined with background interrupt routines (and yeah I know there are 8051 RTOSes, but an 8051 isn't designed for it). Multi-tasking is cleaner and faster to code, easier to maintain, and about even in terms of debugging complexity.

When I read the original post, my first reaction was, Why??? What problem does such a part solve? Upgrades? Maybe, but if a design needs a boost from 8051 to ARM then more than the controller needs to be replaced. If there's a new board, then any compatibilty requirement goes away. New design? Again, why cripple the effort by restricting the design to outdated technolgy, even if it's improved over the original? Port software? Binary isn't going to move, and interpreted 8051 will run slower than the original part. C code can be ported to ARM, but it has to be changed for the peripherals and memory model. Where's the savings in time or money?

Both 8051 and ARM have their place, but they seldom overlap. I use both, sometimes even port C code from one to another, but each has a definite place. I don't use the small Luminary M3s for that reason; the Silabs 8051s do better at the low end. And I don't use the SiLabs 8051-Ethernet combination for the same reason; an ARM with a fast 100Mbit ethernet works much better.