Early morning all (at least in my time zone),
As we see, library naming conventions like this are flawed. But these libraries exist with these names.
And with anything like this, when a new board comes along, that has a different processor, what should you do?
Example: USBHost_t36. When it was originally developed it was only supported on T3.6, but along comes T4 which also has the USB Host support. We have/had several possible solutions:
a) Put the support in the existing library, such that code could hopefully run on either, without source code changes - current solution.
b) Create a duplicate library for T4 and hopefully try to keep them in sync with each other - i.e., along the lines of the cores teensy3 versus teensy4
c) Make 3 libraries - USBHost_common, USBHost_t36, USBHost_t4x - might be cleaner in some ways, but then most all sketches would have #ifdef <t36> - include the t3.6 version else...
d) Jetson this naming convention and create a new one, like: Teensy_USBHost or PJRC_USBHost, along the line of Adafruit or Sparkfun or ..
This is probably a cleaner solution, but a lot of work.
e) go whole hog and change everything. That is currently all Teensy things are installed as one big composit package. And we sort of Lie to Arduino and say everything is built with the architecture of: avr
To be specific, every teensy is considered the same as the Arduino AVR8 based boards like: uno, mega, leonardo. Which works well for Teensy 2.x stuff. And in the beginning of the Arduino ARM stuff, like when Teensy 3.0 came out made sense to continue.
But maybe now that there are many others ARM type boards out there and now with Arduino 2.0 released where we have Teensy Board Manager support, it might make sense, to split this up into at least 2 maybe 3 different board architecture types, in the same way for example: Arduino has: avr, SAM, SAMD, ... Likewise for Adafruit, Sparkfun...
So for example, if this was split into 3, like: avr, kinetis, imxrt1062 (or other names, like, teensy3, teensy4), then, some of the other solutions, could be resolved by the Arduino builder.
For example, today: Teensy build, we install our own version of the libraries: SD and SDFat. Now if I install another SDFat for some other boards, it breaks building for Teensy, likewise if I put the Teensy one in my <sketches>/libraries folder, it breaks building other boards... But if we have specific architectures, like mentioned, we could instead do like what Adafruit does, with their fork of SDFat.
They install as some name like: SdFat_-Adafruit_Fork They still have the main header file SdFat.h as we do, but since they have defined in their library.properties file: architectures=rp2040,nrf52,samd,esp32,*
If you are building for some of their boards, the library builder will probably choose this one over ones that are simply marked: * or avr.
But the main question would be, would the gain of doing something like this be worth the pain? Or would this just be opening up Pandora's box? This probably something that only Paul could answer. But my guess is that this would not be a simple, few hours to convert type thing! And when there is probably so little spare time right now, one would have to weigh this versus that many other things that need attention.
Sorry, hopefully I had enough coffee, that some of this might make some sense.