I see what you're getting at, and bundling together a library of code to detect VBXE, Stereo Pokey, etc, would probably be useful (such things are scattered around on various Wiki pages at the moment). RAM upgrade detection has been covered in a few topics, and since the majority tend to work in largely the same way (i.e. via PORTB bits), the best idea is usually to just establish the number of 16KB banks via software (an application usually doesn't care if an upgrade is RAMBO or Ultimate, only how many banks are available for use). Of course a couple of RAM upgrades used different banking addresses, and now you have the possibility of 65C816 linear RAM to think about as well.
The possibility for overlaps/clashes tends to occur more with control registers rather than RAM itself (i.e. an internal RAM upgrade and a PBI HDD using the same location for the RTC, for instance), but scrupulous research by hardware designers tends to keep things right. There were a few lists floating around the forum a while back describing all the common register locations. It's probably due an update. Meanwhile, a range of hardware is discussed in Phaeron's Altirra Hardware Reference manual, which should be required reading for hardware and software developers alike.
If the idea is to create a binary blob which spits out a software-readable description of what's in the machine, then that could be quite useful, although it would be difficult to create something concise and generic. When writing applications (in my experience, at least), usually one needs to establish a couple of things pertinent to the task at hand. For example, a word processor might need to know a) which DOS is running (in order to handle subdirectories or the lack thereof using a certain set of XIO commands), b) what display device is present (VBXE, etc), and c) how much RAM there is and which bits control it. It need not care whether the RAM belongs to Ultimate 1MB, RAMBO, Compy Shop, etc - just that there is (say) 320KB of it and that SpartaDOS X is already using 16KB of it (and SDX already provides an API for establishing the total RAM in the machine, which bits of PORTB select it, as well as how much RAM is free). With some other DOS (which doesn't report the RAM present), a hardware test is required (which will in turn yield the banking bits). So an intermediate layer would need to interface with both environments.
Meanwhile, the word processor probably will not care (and nor should it, owing to device agnosticism) whether the primary storage device is an IDE Plus 2.0, SIDE2, MIO, Black Box, XF551, SIO2PC or SIO2SD.
Edited by flashjazzcat, Wed May 25, 2016 6:44 PM.