This is going nowhere.

You both try to push the ball to software side. Software side can then try to push the ball back to data side (here) by claiming "it's too risky to decide things in absence of actual data". Someone has to do it; I choose data side. Honestly, what's the actual problem with that changeset other than "this doesn't fit our philosophy"?

There is no way software can correctly distinguish inappropriate u-turns (this) vs legit sliproads. What if there is a legit u-turn that's exactly at this extreme angle? How can software know? This is what I often say as "undecidable". This is exactly what data is for. Not sure why this strange high alert.

It is correct that there is no law prohibiting "u-turn right after junction". However, irl this is almost always inappropriate. We are here as data guys to guide software to not do these kinds of inappropriate routing by creating a new "no u-turn" relation. We tell software, "actually, we do not recommend this". Software may ignore this (e.g. unimplemented) but that becomes their problem, and no longer our burden.

When we already have a "no u-turn" relation, it's natural and probably obligatory to also block the "one edge away" u-turn as a companion to the main "no u-turn" relation itself. This should be trivial.