This is wrong. The reason is that for accessibility to you still need a tag for screen-readers. If templates don't want this then they have to either implement the CSS class or should template override to remove the label. Accessibility should be default shipped with Joomla, not removed

But this is also wrong from a UX point. The users is explicitly telling the module not to display the label and it does regardless of the setting unless using protostar as I suspect that has the CSS in?. In which case the setting should be removed no?

It's show/hide not remove. I mean if you want to make the language string clearer to explain what the parameter does feel free. But this is 100% the correct approach in the frontend.

Ok so in which case, what about changing it to style inline display none? Since it's not working as a show/hide without someone adding custom css. Which they can do without the config option?

I'm pretty sure this class definition (https://github.com/joomla/joomla-cms/blob/79d6abf408a0afbcd8e4d5457acb1f12e6706a2f/media/jui/css/bootstrap-extended.css#L380-L396) was based on an accessibility standard somewhere (i had a quick google but could only find the drupal version of this class). I can't spent too much time searching right now but I'll see if i can dig it out. I think the point was display: none can be ignored by screen-readers off the top of my head. Hence the 1px square thing (which is also what drupal does with the same class name)

How about telling the template developer they need to fix their template as it is missing support for a core feature?

Come on that's being a bit OTT. How are template secs supposed to know about all the classes the core implements?

If the core needs certain classes like this they should be loaded always separately by the core.

How are template secs supposed to know about all the classes the core implements?

How about they follow this repo and see what has changed between versions? In most cases it's enough to check the Protostar CSS to see if anything changes.
But I know many template developers don't care and many templates actually only work for the basic core features and break as soon as an extension uses stuff like modals, popovers and other standard things.

If the core needs certain classes like this they should be loaded always separately by the core.

I'm sure template developers would enjoy that. NOT.

How are template secs supposed to know about all the classes the core implements?

/media/jui/less has the "core" LESS files (https://github.com/joomla/joomla-cms/blob/staging/media/jui/less/bootstrap-extended.less is Joomla specific stuff and the rest of the directory should just be Bootstrap 2.3.2 but who knows what it really is since Joomla likes hacking third party resources). Anything in that directory should either be implemented by a template or have a template specific variant of it (i.e. Bootstrap 3 templates use its grid versus the Bootstrap 2 grid).