Lee Carré (2021-06-06 13:32:09+00:00): “we want to make sure data consumers understand the tagging (at least roughly)”
This is a good point. Though, one hardly ‘consumes’ data; it still exists after use. In fact, more copies exist by using it. The term is a very narrow economic one.
http://www.gnu.org/philosophy/words-to-avoid.html#Consumer
http://www.gnu.org/philosophy/words-to-avoid.html#Consume

Data user, data parser(, data processor?), are more generic & not loaded.

However, it's a double-edged sword. I speak from experience of other contexts (I'll just mention (X)HTML {shudders}).

The risk is one of (basically) tagging according to (current) implementations (all of which will be non-identical, with their own quirks), rather than to soundly designed schemes (and expecting software implementers (implementors?) to keep up). Especially if one is concerned about the long-term, and quality & utility (without the pain of forever preserving backward compatibility). Eventually, innovation stagnates with a chicken-and-egg (who'll be the first-mover) problem.

I imagine that the design decision to use textual tagging was to permit unforeseen / unanticipated scenarios.

Like you say, “Conveying all details as precisely as possible is always a bit tricky”.

“This makes it likely for software to understand it based on a generic scheme.”
In terms of full comprehension; yes. That's also true for any newly-approved proposal, though.

However, it needn't be completely ignorant, either.
Off the top of my head, as a type this, an implementation could treat any significant key (shop, amenity, craft, etc.) which has a(ny) prefix (*:(shop|…)=*) differently to unprefixed “shop=whatever”. Such as, simply (until it has the logic by which to handle each specific case) that the prefix is some kind of modifier, and that it's something other than a running shop. I can imagine using some RegEx for pattern-matching the notation, too.

Whereas, special values (shop=disused) require keyword-matching to avoid a very literal handling.

In fact, this is one of the reasons given for avoiding the likes of shop=vacant, and preferring a prefix.

Prefixes are a generic scheme (which enable & allow for new uses, just as I did).

“An undocumented prefix”
Except that it's not undocumented, only uncommon (but then so are survey reference points). Defacto schemes (by definition) all started out undocumented; the data was the documentation, from which a human-readable form was derived.

“to make any sense out of it”
Having seen such rationale elsewhere, one of the reasons for textual tagging is likely that any which are unfamiliar to a parser (optional or new ones) can be ignored while still being able to read the remaining data.

“human reader has an intuitive understanding”
While I agree with your meaning, having studied usability a fair amount, the term is risky (especially when one means something else). So, interpretative understanding, perhaps?

For context; in usability, intuitive!=usable. Intuition differs across cultures.

“software has not.”
Commonly, yes. However, it can be given the ability to make not-unreasonable decisions. That's down to the care of the developers, though.

The other side of that coin (or sword, to use the earlier metaphor) is that lack of distinction between semantically-different cases prevents diligent implementations from doing clever or innovative things.

I recall (for a different changeset, yesterday) that this is why diet:* came into existence; to avoid several cases of ambiguity when (previously) using cuisine=* for both (e.g. which of the following does cuisine=indian;vegetarian mean; vegetarian-only Indian dishes (Indian AND vegetarian), or (Indian OR (non-Indian-)vegetarian), or Indian dishes which can be made vegetarian-compliant (Indian OR (vegetarian AND Indian)) (or something else I can't think of 🙂)?)

However, perhaps this is why the proposal mechanism came to be. Maybe I'm simply retreading old (and well-discussed) ground.

Your point about using editing software, though; since that definitely affects me, it would certainly be simpler to use presets (which would tag as disused:*) rather than entirely manually (especially as you already caught one goof I made (with internet:access); I can only imagine it being because by that point (after a day of surveying) I was tired, cold, or both).