I want to add sys._wasi_info, but I noticed that everything in sys which stores any structured data uses structseq. But since sys._wasi_info will be new there’s no need to support an index API. And yet it almost feels weird not using structseq since everything else in that module does it that way.
Are there any objections to not using structseq?
Don’t you worry that someday, someone will file a bug saying they’d like to use the index API on this object, but, unlike every other struct in sys, it doesn’t support it?
IMO it’s a good thing to add the tuple API to new sys members (so not use structseq). We can add it later, if someone comes with a good use case for it.
I proposed to deprecate the tuple API of existing sys objects, but multiple users asked to keep it: Deprecate the tuple API (object[index]) of structseq objects like os.stat_result.
Not everything; sys.implementation & sys.abi_info aren’t sequences. Add the next one :)
If I go the mapping route I could use a frozendict and be a trailblazer! 
I like frozendict (what a surprise!), but, usually sys objects have attributes, rather than using the mapping API, no? Like sys.version_info.major instead of sys.version_info['major'].
Hence the whole point of me asking the question. There’s a lot of “usually” in the module, but it’s a bit all over and a lot of it is historical.
About frozen stuff in sys, sys.stdlib_module_names is a frozenset 
I think it would be a good idea to not use structseq.
I’m getting confused about what’s being asked now. I thought the idea was that the object would have attributes, but you didn’t want to support tuple-like behaviour (numeric indexes and unpacking). I’m fine with that.
But the discussion has veered over to a (frozen)dict-like interface, where the object is indexed by strings. I’m not so keen on that - for this type of object I find the mapping interface much less convenient than attribute access.
Correct.
That’s my fault for misreading the code for sys.implementation and sys.abi_info; they build a dict but then create a namespace object at the very end which I missed. So I will just plan to do that.