Lee Carré (2021-10-15 09:47:55+00:00): “The "issue" with the current way of work of iD is that anybody can write anything in the box and it will pull the closest match from taginfo. If there is no "tires" in taginfo, it won't suggest it. I'm "taking the firehose out of the house" by removing the service:vehicle:tires tag.”

You're still thinking about it narrowly in terms of data, not process or user-experience.

You say that with iD anyone can type any value (rather than proper presets with pre-existing (checkboxes, radio buttons, drop-down list) suggested values). So, what's to stop someone typing tires and assuming that it was simply missing from taginfo (if they even know that's where the matching values come from)?

How do they know what to begin typing without any (pre-typing, which is essentially guesswork) hints?

Ultimately, what's to stop a repeat? That may well be how it started.

So, no, the firehose hasn't been removed, and while you may have done only one mopping, that's only so far (and by you alone). I don't see that the (root) causal mechanism has been remedied.

“As you can see in taginfo it's not being used anymore and there were no other new uses. Note that I didn't have to do any additional clean up after the first "mopping".”

So far, perhaps; otherwise no, I see no such thing (with confidence, long-term). Your earlier description of iD's behaviour remains, and at least one vector hasn't been mitigated. Which was my original point when mentioning presets.

You want the conclusion to be true, but saying that it's true doesn't make it so.

Not really any different to a politician saying that there'll be zero murder in future because he's prevented it by making it illegal. Right; nice intention, but how does that actually prevent murder (and an exasperated ‘because I changed some legislation’) doesn't really convince or add anything.
The faulty assumption is that illegal==impossible.

“Developers usually don't have to do that sort of pattern matching since they could just query for all features with some tags. In case they only request one of the tags, they will notice that the data suddenly disappeared and they will (or at least they should) take action to fix their software.”

This misses the point, makes many assumptions, and ignores one of the conditionals I specified.

Well-implemented software will still need pattern-matching to query tags (for any reason, be it to find features, or determine detailed properties of each). You're assuming that this somehow won't break, yet querying other tags will. That's not internally-consistent. Again with the presuppositions and pole-vaulting to conclusions.

You assume that developers will be monitoring each instance of software they release. Maybe if a home-brew script running on their own hardware, but not something released for others to use.

I preempted the scenario which you describe: savvy developers will want to avoid & prevent their parser being fragile in the first place. Thus, they'll use pattern-matching (defensive design, not trusting (sanitising) input, being tolerant of errors, wanting robust software). Why wait until it breaks, out in the wild, before accounting for an obvious failure-mode? Just use pattern-matching from the start.

Imagine if that attitude was applied to security and/or safety systems.

“Assuming US English is what you meant by "Yankish".”

I meant what I said. English is spoken in England. What's spoken in the collection of states between Mexico & Canada is something else (for so many reasons).

An unambiguous term for the Americans between Canada & Mexico is Yanks. Thus Yanks speak Yankish.
You're independent, after all.

😄