With a future-looking perspective in mind, I'd personally lean towards the "more powerful defer" option, even if it'd mean it'd have to come sometime later.
It has a number of benefits:
- it is a nice improvement in the language in general
- we've also had thoughts about using defer to "guarantee cleanup, even in cancelled tasks" which also may imply defer changes
- for the same reasons allowing async code in defer might be good -- so there could be
defer async - overall it seems like defer getting more powerful would be a generally welcome thing, not only for the macro reasons
- it fits and empowers preamble macros
- more features that fit eachother nicely rather than more specialized macro kinds sounds like a good route forward for the long term
We may have to live with a body replacement macro for tracing for the short term, but the new defer capabilities could then arrive sometime and we'd switch over to a more composable one...
(we'd still need the task local's unsafe APIs but we can do those rather quickly).
So... trying not to derail the current review: I think this would be okey to keep as is, and try to follow up with more powerful defer -- might be good to get a take from the core team if that's somethign we could consider.