What would we expect to happen if the ACPI and DT content are not equivalent?
Then the OS would get the functionality of whichever system description it chose. The experiments with ACPI-only OSes on Arm SBCs have shown that there is interest in supporting the platforms, even if the initial functionality is reduced due the not all hardware having a usable ACPI description (lots of reasons for this from hardware design not fitting nicely into the ACPI model, to lack of bindings, to just hasn't been looked at yet)
Also network and storage interface, possibly others, names often change just due to the way naming//bindings/IDs are handled between the two.
The crux of the matter is that platform X described via ACPI cannot be assumed to be the same as platform X described via DT. Peter points out the device naming changes due to different enumeration order, but there are many other issues (NUMA topology, RAS features etc). So there can be no guarantee whatsoever on OSes that are able to support both descriptions that any OS or HW configuration state can be preserved across a switch from ACPI to DT or vice versa.
I understand how on the face of it, permitting both to coexist might seem like the easiest approach from the platform vendor POV, but I think this is a mistake. Making it the system's job to choose one description or the other removes any ambiguity, and therefore prevents problems. I understand how OSVs like MS entering the space that has historically been dominated by DT are eager to make the switch seamless for them, but doing so creates problems for Linux, so I would prefer not to go down this path.
To be honest I'm inclined to the view that it is having a single product supporting both DT and ACPI is what creates the problems for Linux. There are two options and the best option may well be different for different Linux kernels: stable kernels probably want ACPI until the board is very mature and linux-next and vendor kernels probably run best in with device tree[1]. Somewhere in the middle there is a cross-over point.
I'm not clear why making the OS bootloader choose the h/ware description instead of the system providing a user-controlled choice will makes this problem worse (or better).
More than that however, to really understand things I'd like to more clear about the type of products that are envisaged that would possess both ACPI and DT descriptions. It hard to understand how an true embedded product would need to do this! Are we concerned about reference software shipped by SoC, SoM and dev board vendors or does it go deeper than that?
The Raspberry Pi is a great real world example. Linux support for the PI is mature with DT and makes heavy use of overlays to modify the configuration of the platform. For the foreseeable future DT will remain the preferred RPi system description. At the same time there has been a lot of activity to bring up ACPI on the Pi to support Windows and VMWare ESXi. The EDK2 port to the pi carries both DT and ACPI descriptions. Windows, Linux and ESXi boot out of the box. Linux chooses DT by default. Windows and ESXi use ACPI. The user doenn't need to reconfigure firmware to run one or the other.
The ACPI implementation there isn't particularly mature and doesn't support overlays or anything other than the "server" use case of the RPi, there are people "supporting" that EDK2 version on Fedora, and by "support" I mean making builds and testing the very basic "USB, ethernet, serial console" and when users complain and I on forward the issues they basically ignore it. The over all experience there for the end user is quite dreadful. I would use that particular usecase as an example not to support multiple options in the one firmware TBH.