Given that this currently seems blocked on the broad question of "how should additions and removals to the stdlib be managed", I'd like to not focus too hard just yet on the specifics of tomli. I assume it's unlikely, but for all we know, the SC could determine that all newly included modules have to be written from scratch, following along the lines of recent additions like zoneinfo, graphlib and importlib.metadata.

There's a lot we could bikeshed or debate... e.g., it's not even clear to me what a toml package in the stdlib would be named, never mind what it means for an unreleased version of a commonly used third party toml package dropping support for an imminently EOL version of Python. I'm possibly totally out of line, but in my head, the process would look something like this:

Step 1: Hear back from the SC about criteria and considerations for new modules in the stdlib
Step 2: Determine whether a TOML library *in the abstract* is something that would meet the outlined criteria (potentially e.g. is this something we even want? is this something we can maintain?)
Step 3: Determine if we have an implementation (written from scratch, copied, or derived from something pre-existing) that would meet the outlined criteria
Step 4: Do all the rest of the work to meet the outlined criteria (potentially e.g. go through PEP process, create proposed impl, write a backport, bikeshed api and name, etc)

I guess I have the following questions:

- Is my understanding correct that this issue is blocked on SC guidance?
- Is there anything we could do in advance of SC guidance that would be productive?
  Brett previously mentioned bringing it up with the author of tomli, as per https://github.com/hukkin/tomli/issues/141 they seem supportive
- Is there a good place to follow along or be notified of SC thoughts?
  I see no mention of stdlib changes in https://github.com/python/steering-council and the discuss thread linked above seems to have petered out.