At least I and Ethan and Martin have expressed a desire for the default, preferred usage work well in a portable environment. Requiring `delete_on_close=False` violates that expectation.

How about something like this instead:

- Add an `delete_when=None`, also accepting "close" and "exit".
- "close" means delete on close.
- "exit" means delete when the context manager exits.
- When `delete_when` is None, the default behavior is selected (currently `close`).
- At some point (now or in the future), raise a deprecation warning if `delete_when=None` is passed (require it to be explicit) and explain that the default in the future will be `delete_when="exit"`.
- Document that passing an explicit `None` for `delete_when` is not supported (don't do it).
- In a release after the deprecation has been released, change the default to `delete_when="exit"` and drop support for `None`.


Note, this deprecation approach could be enacted with "delete_on_close" and boolean values, but I prefer more explicit values for shorter-named variables.


This approach would allow a user to opt in to the future behavior which has the desired effect of preferring the default behavior (in as little as two releases).

I might be tempted to create a `backports` package for users of earlier Python versions to get the future behavior sooner.