> you added a late binding optimization for the whole uname return
tuple to save the effort of ... shell access.

It wasn't to save the effort and it wasn't an optimization. There was a fundamental race condition where it became impossible to implement a `uname` command using Python because `platform.system()` (or anything else that delegated to `platform.uname()`) would unconditionally shell out to `uname`, and this would happen early, before a library could intercept the behavior. See issue35967 for more details on the motivation and challenges.

> I think this would have been better implemented...

This idea is interesting, but I believe it also falls prey to the same race condition if any code calls `platform.uname()` before a Python-based uname implementation has a chance to monkeypatch the behavior.

May I suggest that you either revive the conversation in issue35967 or open a new ticket to discuss improving the implementation so that the details aren't lost in this ticket, which was specifically about compatibility issues?

> I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.

I'll address this concern in the ticket I opened about the deprecation.