That's crazy. Modifying an already-working CPU design to remove hardware features, and modifying Rosetta to implement that capability in software instead, or wholly replacing Rosetta with FEX, would all require investing more resources and effort than continuing to ship what's already done and working.

> I think that Apple’s overall mentality has traditionally been that they provide enough time for developers to transition applications but that they are not interested in maintaining support for unmaintained apps. That seems to be a very clear pattern of behavior.

Fair enough, but we don't actually have to make projections based on past patterns of behavior when Apple has explicitly shared their plans. They do plan to maintain support for unmaintained games.

I think the only reasonable way to interpret what Apple has said about their plans for Rosetta is to assume they're not likely to muck about with the low-level details of how they handle running x86 machine code, but they are likely to start dropping some x86 libraries from the OS, breaking applications that depend on them. We can reasonably expect that they're retain all the pieces necessary for running x86 Windows software (especially games) under Wine. (Keep in mind that Apple's approach is to not mix x86 and Arm code in the same process; they didn't do anything like Microsoft's Arm64EC.)

Link, please.

> and perhaps not coincidentally all of the Plus laptops require reversing

You're still acting as though Qualcomm has made meaningful contributions to Linux support for Snapdragon X Elite in a way that has not also helped Snapdragon X Plus support. But you haven't specifically pointed to any Qualcomm contributions of any nature, let alone ones that were as narrow as you claim. All you've done is point to weak evidence that machines with Snapdragon X Elite bins reached a reasonable threshold of "supported" earlier than models with lesser parts, while ignoring that your evidence also points to the lower-tier processors coming to market later.

Can you point to any laptop device tree that was contributed by Qualcomm, and not merely reverse-engineered from the device tree for the reference design that was not offered for sale to consumers? Can you point to any driver contributed by Qualcomm that works for Snapdragon X Elite SoCs but requires further modification to work for Snapdragon X Plus SoCs?

You made a claim about a pattern in Qualcomm's public behavior, and have identified zero instances of that pattern.