an alternative (if parseable, I have not fully thought about that) would be to leave out the KEYW-TO-BE and try to parse directly
kind name [ '(' expr,... ')' ] [ maybe  extended syntax ]:
where kind could be any general expr or better only a qualified name that are NOT keywords, so we would possible have:
all working as specified like 'class' and with its scope rules.
The problem is that this is much harder for the LL(1) parser; otherwise I like it fine. The name being defined (foo and I above) would be available to the code implementing 'kind', which is useful.
What's still missing is a way to add formal parameters to the thunk -- I presume that J and K are evaluated before interface.interface is called. The thunk syntax could be extended to allow this; maybe this can too. E.g.:
e:(x, y): S
would create a thunk with two formal parameters, x and y; and when e calls the thunk, it has to call it with two arguments which will be placed in x and y. But this is a half-baked idea, and the syntax I show here is ambiguous.
Control flow statements would still have to be added to the language one by one (I find that ok and pythonic).
I disagree; there's a number of abstractions like synchronized that would be very useful to have.
Also because specifying and implementing implicit thunk with proper scoping and non-local return etc does not (to me) seem worth the complication.
See my other post.
About extending or generalizing function 'def' beyond  extended syntax, I don't see a compelling case.
--Guido van Rossum (home page: http://www.python.org/~guido/)