I'm going to attempt to answer my own question here, by reading and quoting from the current 1.0C version of the ARM Base System Architecture specification[1].
Quoting from page 13 of 98, section number two, entitled "Introduction":
The primary goal of this document is to ensure sufficient standard system architecture to enable a suitably built single OS image to run on all hardware compliant with this specification. A driver-based model for advanced platform capabilities beyond basic system configuration and boot is required. However, this is outside the scope of this document. Fully discoverable and describable peripherals aid the implementation of this type of driver model.
So I think that the specification is intended to achieve this.
My understanding is that the ARM Base System Architecture is the abstract, top-level compatibility specification, and that within it there are more-granular boot specifications, including EBBR (E for embedded, and does not require ACPI for compliance) and SBBR (S for server, and does require ACPI for compliance). These are then bundled into compliance specifications, presumably for QA and testing purposes (ARM SystemReady IR where the I may be awkwardly for Internet-of-Things, SystemReady ES for Embedded Server, and so on. the ARM Developer Ecosystem SystemReady guides[2] are a useful reference for this).
So overall for ARM: the situation looks like it should be better in future in terms of single-OS-image compatibility across systems. For whatever reasons, only Internet-of-Things compliance category devices have been specified without ACPI as a requirement, although the base specification (Base System Architecture) that each compliance category devices from does allow for DeviceTree as an alternative. And that, I think, would be fine by using the 'compatibility' field to allow systems to be installable, bootable, usable even if more-tailored DeviceTree information would subsequently allow for improved access to a given platform's devices. But again, I don't really understand this stuff in detail, so that's my fairly naive read of the situation.
no subject
I'm going to attempt to answer my own question here, by reading and quoting from the current 1.0C version of the ARM Base System Architecture specification[1].
Quoting from page 13 of 98, section number two, entitled "Introduction":
So I think that the specification is intended to achieve this.
My understanding is that the ARM Base System Architecture is the abstract, top-level compatibility specification, and that within it there are more-granular boot specifications, including EBBR (E for embedded, and does not require ACPI for compliance) and SBBR (S for server, and does require ACPI for compliance). These are then bundled into compliance specifications, presumably for QA and testing purposes (ARM SystemReady IR where the I may be awkwardly for Internet-of-Things, SystemReady ES for Embedded Server, and so on. the ARM Developer Ecosystem SystemReady guides[2] are a useful reference for this).
So overall for ARM: the situation looks like it should be better in future in terms of single-OS-image compatibility across systems. For whatever reasons, only Internet-of-Things compliance category devices have been specified without ACPI as a requirement, although the base specification (Base System Architecture) that each compliance category devices from does allow for DeviceTree as an alternative. And that, I think, would be fine by using the 'compatibility' field to allow systems to be installable, bootable, usable even if more-tailored DeviceTree information would subsequently allow for improved access to a given platform's devices. But again, I don't really understand this stuff in detail, so that's my fairly naive read of the situation.
[1] - https://developer.arm.com/documentation/den0094/c
[2] - https://github.com/ArmDeveloperEcosystem/systemready-guides/blob/1211c0176eacd306024686d0edb9846d199db10e/README.md