Rumor smells funny to me. I'd be very surprised if we ever see that many efficiency cores on a desktop. Especially nearly 20% efficiency cores.
It wouldn't be surprising if Apple were going to try to use the same SoC "Building block" for the whole rest of the line up. ( e.g. iPad Pro -> lower end mini + lower end laptops gets one design , MBP 14-16 , iMac , Mac Pro "short" , Mac Pro "tall" gets a more enabld building block. )
That would get rid of Apple's not enough volume to scale with the Mac Pro. If MBP 16" and iMac 27 (or 32") were soaking up most of the SoCs then it gets the volume to get green light. The Mac Pro just "makes do" with what is available.
So if have a basic 16 core building block ( 12 big, 4 small , GPU block , NPU block , etc. ) then
It would be a major departure from the M1 but if had a "Unified Memory Inter-package" crosslink hub then can get to 32 cores with a just closely bonding two SoCs together on the main board. Mirror that dual cluster along the bottom edge and could have point to point one hop links to all three "neighbors.". Apple could use the high speed interconnect not using on the non "four corners" edge to link up a limited PCI-e v5 hub/switch for slots (which the vast majority of the rest of Mac line up won't need. ) or hook a in house 5G modem ( which iMac, "max" Mini or Mac Pro may not need. ) .
A short Mac Pro with 2-3 slots might get just one PCI-e hub/switch whereas a "tall" Mac Pro could get two (and still provision out 7-8 slots ).
Apple doesn't have to reinvent the wheel here. CXL over PCI-e v5 physical foundation could be the interpackage link. Or they could invent their own.
For the single , SoC building block set up it could have a decent of "dead" high speed links but Apple can make those users just "eat" the costs. Similar on other end of the spectrum. It would be advent of the real nightmare some folks have dreaded where buying more RAM means making folks buy more cores too ( and extra Secure enclaves not using).
Could have incrementally lower RAM costs with just two 16GB stacks per building block. ( e.g. 32 cores and just 64GB ). Pretty good chance Apple would loose more than a few folks in the > 256GB data working set footprint market , but I suspect they wouldn't loose sleep over that if it cleaned up overall development path.
[ The iMac 24" ethernet port is out in the power dongle now, because had to turn that imac into bonus sized iPad in terms of thickness. ]
The GPU cores spread out over 2-4 packages will probably be decent for "compute" but probably won't win any major frame rate and/or large mega resolution monitor battles with AMD/Nvidia's top offerings. Again I doubt Apple will be pressed about that. ( Even more so if eventually let AMD back in the door as an option on Mac Pro's and perhaps large screen iMacs. )
Apple would also need to make some substantiative additions to hardware performance management logic ( and/or OS kernel changes) to distribute/manage the loads over the four packages. But the lower the fixed max number of packages should make that tractable.
It's a big desktop. Why would you implement power efficient cores? And M1 efficiency cores seem even more underpowered than their mobile counterparts.
As more apps expect there to be be power efficient cores laying around, some will spawn off more work to them. If mostly have developers highly weaned on developing phone apps that number is even higher.
I haven't seen much evidence that these power efficient cores are any "weaker" than the other ones in A13/A14. To the contrary, core development is rumored to be all "hand me down " iPhone cores just packaged differently.
( The M1 is in the iPad Pro just as much as it is in the MBA ).
In short, not particularly funny if walk away from premise that Apple is going to build something specific just for the Mac Pro. if they are not then probably stuff more targeted at those other Macs is going to seep into the Mac Pro configurations. IMHO, minimally going to get iGPU cores in the mix. wouldn't be too surprising is the power efficient cores came along for the ride also.