Theme developers are forced to use SMACSS

@laurii: Amen!! Word!

Just found this here because I was about to start an issue but saw now by searching that it already exist. And since laurii already perfectly outlined the issue I think I just can add the css comment I put in the head of all libraries yml files of all our themes.

  1 # Main theme library.
  2 # The SMACSS nesting layout is required (sadly).
  3 # That's why the theme: subgroup comes in here.
  4 # Which makes no sense at this level since Drupal should
  5 # rather provide as a flexible theme "connector" here.
  6 # We repeat mistakes we made in Drupal versions before
  7 # and force inhouse outlining on middleware levels.
  8 # Not all frameworks can follow or can be re-outlined
  9 # to this or are already outlined before this level.
10 # Feel free the rename or re-outline but one nesting level
11 # is sadly required.

The world of web is full of such ideas like SMACSS and yes even me had some motivation 10 years ago to start a CSS outlining project called QCSS and all this ideas are wonderful. But we should learn that it is not for everyone and especially - and this is the most important think to learn - not for every scenario. I can't count no more how often I sad that. Also in other topics like headless Drupal, OOP, package and dependency managers of programming or scripting language engines and so on. All very important innovations and improvements in Web development technologies or programming/scripting languages on other enviroments. But everything has always to be taken with a grain of salt and the day will come where disadvantages start to pop up. SMACSS is great but some theming frameworks maybe used it already a level before and after sass compiling delivers only one CSS file? In this case the additional theme: subgroup is just for the purpose to keep the library file functioning.

Otherwise the library file will simply not be loaded. This is why this issue is still up-to-date.

Since this pattern is very deeply seated into Drupal it is rather a complete paradigm change we discuss here. Not only a change on the outter surfaces of the theming layer. Not sure if this will enter any serious progress any soon. But still, I strongly advocate for seriously reconsidering it.

From my findings following the functioning and its connections it leads from
core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php
to
core/includes/common.inc
where the constants based on SMACSS and for other default weighting purposes are defined already.