> The former sounds like fixing the bug, the latter like removing functionality. So yes, I prefer the former...

The reason I'm reluctant is that it makes for a fundamental change in
behaviour between the use of an @contextmanager definition as a
context manager and as a decorator. The former would continue to be a
one-shot operation, just like opening a file and implicitly closing it
at the end. The latter (if fixed) would need to implicitly recreate
the context manager on each call to the function, creating the
illusion of the context manager being reusable. The difference in
underlying behaviour bothers me a great deal, as does the effective
creation of a "context decorator" protocol that is the moral
equivalent of the implicit context manager __with__ method that
received barely any interest when I posted it on python-ideas.

Given that it is impossible for anyone to be using this feature at
this stage (since we just added it and it doesn't actually work in
practice), I would prefer to simply acknowledge that I screwed up in
failing to completely think through the implications of adding it and
ditch it completely. If someone really wants this functionality to
work, then they can do it right and write the implicit context manager
PEP. (Note that ContextDecorator itself is fine, as long as the
context manager is reusable. It's the fact that ContextGenerator
*isn't* reusable that causes problems).