The point you're missing is that I'm not the one suggesting a change here - you are.
The "standard" you're claiming exists really doesn't, it is nothing more than (your) personal preference. Some folks will agree with that preference, others won't.

There's entire road networks that are not mapped the way you're claiming is the norm.
The status quo is simply that there is no (community-approved) standard for whether to include the refs on the ways if they're already on the relation. If you want to change that, again, please follow the proposal process to establish a standard (be that to always include them, never include them, or something in between). Until then, mappers will do what makes the most sense to them. For me personally, that means not duplicating the refs and fake-tagging them as attributes of ways, when semantically, they're really attributes of the relation, just to satisfy a renderer.

TIGER or not was not the point - the point was that your "but there's a lot of examples on the map that support my preference, and that makes it the standard" argument is flawed.

The process you're describing (=filling in stuff based on history that may or may not have been right) and without verifying whether these segments are actually currently(!) part of that route, is precisely what I expected, and why I believe these are undiscussed mechanical edits. The part that is clearly missing is verification that each of the segments you tagged is indeed part of the route right now.

De facto doesn't make anything a standard, a proposal does.
De facto, millions of road segments have tiger tags from old imports. That doesn't make keeping them a standard in any fashion.
De facto, large areas of the US are missing building footprints. That doesn't make "no buildings" a standard.
De facto massive amounts of major roads have lane tags not matching the ground truth along the entirety of the segment, because someone looked at a subsection of that way at some point only when they tagged the entire segment. Again, that doesn't make having miles and miles of road tagged as two-lane the standard when in reality there's sections turn lanes along that segment.

If you want to enforce your preferred tagging style as the standard, there is a process for that - a proposal. Until then, please respect that your preferred style is not everybody else's preferred style.

Also, be careful with just blindly "inferring" that every way in a route relation should have the segments tagged and forcing these tags in without any further verification. This probably fits the definition of a mechanical edit (which I'm assuming was not discussed in the proper channels either?)

hold on for just one second though - would you mind sharing a link to the proposal that established the tagging style you seem to be preferring personally as "the standard"? All I'm seeing under that link looks like a random dude's opinion on a wiki page - that doesn't quite meet the bar for what I would consider standard. Especially, if the main argument there (and the one you chose to reference here) essentially boils down to "tag for the renderer" (when there is no ground truth for the tags on each of the way segments contributing to the relation).

because the ref sits on the relation (1656989)

are you sure about the name change on way/178411958? The park district lists this as Fox Hill Park on their website, and that's also consistent with what's visible on the sign in bing streetside imagery. Google Maps shows this location as Wheatlands park, but copying anything from gmaps is a copyright/license violation...

Hi there - thanks for catching this. I have a preset for blank addresses which makes address tagging from scratch somewhat more efficient for me, and must have used the wrong keyboard shortcut (bound to this preset) by mistake. There's nothing automated about it. This was meant to be tagged noexit=yes instead. Fixed in changeset/150106083.