Yes, but the problem of this thinking is that when communicating we inherently look for shortcuts and shaping language to the context rather than sticking strictly to a grammar and a dictionary, and to be successful at defining a natural language (and that includes diagrams) you need to accept that the job is 90% describing reality and 10% trying to shape it. If that.

UML has been reasonably successful where it described reality, or tried to gently shape things by proposing things that were close to how most people already did things. Much less so where it tried to prescribe a reality not aligned with how people communicates, or where it has not kept up with the way that has evolved. It'd be more successful at being a lingua franca if the focus was more on documenting how people actually use diagrams, and just provide gentle nudges in one or the other direction where use is inconsistent.

I think this is also why so many people hate UML tooling - because it forces you to communicate in this strange dialect that is very different from how most of us communicate with diagrams, and that most people find awkward.

I think the problem comes from the difference between "modelling" as in the CS field of modelling and diagram generation for documentation purpose.

They are fundamentally two different use-cases which just seem similar if you ignore all the subtle but important details.

But UML tries to bridge both by having something you roughly could describes of "layers" of details.

But for documentation, especially tutorials, well suited diagrams aren't often just simplified by omitting/grouping details or similar. They are often simplified in ways which makes them subtle wrong in ways anyone getting started with the software can ignore and (hopefully) a foot note about this wrongness.

And most times for most people it's only ever used for less formal diagrams instead of "proper modelling". And more often for on-boarding/tutorial documentation then for deep technical documentation.

UML sucked so much, it took OOP down the drain along with it. Unfortunately, UML also had to contaminate nascent BPM modeling, by making BPMN a fscking "profile" of UML. I'll never forget the look of once motivated process modelers when they learned they need "stereotypes" and such - the result of their modeling was more like a psychoanalysis and beyond useless. Ever had to deal with RMI, EMF, MOF, and UML's weird and unsound meta-modelling "in itself" for exchanging model data modulo the worst of XML? To hell with it.