There is really nothing to say they can't call these M1 as well. They can just be 16-Core (or more) variants. the X variants of the A series came out later and the only differences were the number of CPU/CPU cores. I would suspect a version number change would only come about after a change in design of the actual cpu/gpu/neural cores.
One of the things that I have noticed is that Apple advertisers the current M1 Macs as "8-core" which makes me believe this will be a significant point of differentiation in future products.
Spoken like someone who doesn't understand any of the technical issues.
There are multiple dimensions along which the M1 is unsatisfactory for higher-end machines, and these are not easily fixed within the existing M1 framework:
- more cores (requires new masks, yes, but probably requires a lot more than that. Apple's current design clusters up to 4 performance cores as sharing a single L2. You probably don't want to scale that sharing beyond 4 cores or so. Which means the next design will probably replicate multiple of the 4-core+L2 clusters.
The good news is that Apple has already engaged in some of the work required by such a design, since the current designs already have a Performance cluster and an Efficiency cluster. But that's not all the work... There are issues like how the OS will schedule threads across these two performance clusters. There are technical issues like how interrupts will be routed across different clusters, or how TLB teardown will happen. It's not like these are impossible problems; but they are problems new to Apple, and one thing we have constantly seen with Apple is that rather than do things the "usual" way (which in the case of interrupts or TLB teardown, is really becoming a problem at large core numbers) they'd rather implement something completely new, which is risky but has paid off massively for them ever since the A6.
- more GPU.
- more RAM. Some aspects of more RAM are easy -- sure, you could reach 32GiB by putting two RAM chips on the other side of the SoC, or by putting them on the other side of the existing RAM chips (poor man's 3D stacking!) But there is the larger question of how do you want to support the truly large RAM footprints (1TB or more) desired by some Mac Pro customers? The obvious solution is a "minimal" RAM footprint directly on the package, plus expansion via something like CXL. But is that what they will choose? And of course that requires PCIe5 and a CXL controller designed into the SoC...
- more IO conectivity. Once again look at the grumbling about having only one "official" display connection and only two TB connections. People buying an iMac Pro/27" iMac will want at least 10G ethernet + 4TB + 4USB like they have right now.
- there is the basic question of how do you support a range from the demands of a macBook Pro up to a mac Pro (which might want about 4x the CPUs and GPUs of the macBook Pro), but do so at reasonable given that *all* these products together don't sell in very high volumes. The obvious answer is some sort of chiplet-type solution -- a baseline "M2X" chiplet, that can be cross-connected to one, two, or three other such chiplets. But once again now we're talking a completely different type of design; not just the packaging but the very basics of having connectivity (wiring points, and inter-chiplet communication protocol) between the chiplets, something that we've never seen on a prior Apple design.
The point is not that an M1 couldn't be redesigned to provide some of these (not all -- there's no PCIe5 and CXL on the M1, and replicating more of the PCIe4 lanes won't change that). It's that such a design makes little sense. Start with the newer better CPU (A15, with SVE/2 and ARM9), use a SoC design that's aimed at a "larger" product rather than sub-optimal modifications of a product with a different design target.