I agree with Raymond here - the standard library's startup benchmarks are *NOT* normal code execution paths, since normal code execution is dominated by the actual operation being performed, and hence startup micro-optimizations vanish into the noise.

Accordingly, we should *not* be redesigning existing standard interfaces simply for the sake of allowing them to be used during startup without significantly slowing down the interpreter startup benchmark.

By contrast, it *is* entirely OK to introduce specialised types specifically for internal use (including during startup), and only making them available at the Python level through the types module (e.g. types.MappingProxyType, types.SimpleNamespace).

At the moment, the internal PyStructSequence type used to define sys.flags, sys.version_info, etc *isn't* exposed that way, so efforts to allow the use of namedtuple-style interfaces in modules that don't want to use namedtuple itself would likely be better directed towards making that established type available and usable through the types module, rather than towards altering namedtuple.

That approach would have the potential to solve both the interpreter startup optimisation problem (as the "types" module mainly just exposes thing defined by the interpreter implementation, not new Python level classes), *and* provide an alternate option for folks that have pre-emptively decided that namedtuple is going to be "too slow" for their purposes without actually measuring the relative performance in the context of their application.