Hey,
Soc and mcu family relations and naming schemes should be respected as well.
Well, there's always the tradeoff between consistency within RIOT and consistency with whatever a vendor does to sort it's MCU variants.
I must say that I prefer the RIOT naming scheme, which is more or less unified over all the vendors. If not because we as RIOT developers have it easier to navigate in quite a large code base, then because a large part of RIOT's appeal is the abstraction of actual hardware it offers, across a wide range of platforms.
The relationships do not need to be elaborately reflected in build automation as just following the naming schemes is enough to tell the reader how they are related.
Well, we do have a build matrix with ~5k entries. Build automation goes a long way, and the more we can declare using conventions, the less we have to maintain.
I'm personally more familiar with ST and their Nucleo64 family of boards and STM32 family of MCU, so I cannot suggest anything specific detail for this particular discussion.
I think that state reflects that of many RIOTers: there's a lot of experience with one (or some) MCU families, and less to none with others.
When bringing up a new MCU family, I usually do my first steps with the platform, so the vendor's family relations are not clear yet. It is usually only when adding the second member of a family that I can assess how similar they are.
Add to that the complication that sometimes we add support for a specific MCU before other family members are available or even announced.
So I think the way we currently do it is sound, which is incrementally adding common folders as soon as it makes sense (saves duplicate code, ...), using a scheme similar (if not consistent) across supported boards/MCUs.
But as I'm probably biased, do others feel that the folder scheme should more reflect a vendor's scheme?
Kaspar