The LSG discussed this proposal today in order to determine what we would consider bringing to review, mostly focused on what seems to be the primary remaining point of consternation: the default behavior of task locals. The LSG decided that in order for this proposal to come back for a second round of review, the proposal should remove any guarantees around the availability of task locals within an isolated deinit, regardless of how the call is scheduled. This is the option that 'does the least' both from a performance standpoint as well as from the standpoint of what promises the language makes.
The LSG acknowledged that it is of course possible to construct setups which would potentially exhibit meaningful behavior changes upon adopting isolated deinit, but believes that actual real-world use cases for reliable task local values in isolated deinit would be exceedingly rare and felt that the potential performance impact of messing with the task locals was the weightier concern. And moreover, because isolated deinit requires explicit adoption (as requested after the previous review), users who are concerned about having reliable access to task local values within their deinit will not have behavior change on them unexpectedly.
The LSG also noted that beginning with the behavior that makes fewer guarantees is the more conservative option: if the proposal is accepted, and if usage isolated deinit bears out that there is a strong demand for reliable task local behavior, it would potentially be an option to apply different behavior by default since that would be a 'strengthening' of the contract.