To note, many of the examples given assign the result of the lambda expression to a name, which is not an intended use of a lambda and highly discouraged/unidiomatic to begin with (as opposed to using def, as intended). See this recent discussion for more on why, as well as how lambdas and their syntax fit into the language.
As @steven.daprano points out, function object are constructed via an object constructor, types.FunctionType(); its just rather tedious and inelegant to do so. At a low level, def and lambda can be roughly be thought of as syntactic sugar for types.FunctionType() that makes this far less painful, clearer and more elegant. Your proposed syntax is not an object constructor either, and fundamentally at odds with the basic grammar of Python with regard to statements, callables and blocks.
While a minimal reproducible example is useful for isolating a bug, I think what we’re asking for here are useful real-world (not just theoretical) examples where the limitation has serious negative repercussions, and the proposed new syntax would have substantial tangible benefits for a significant fraction of users sufficient to justify such a relatively large change.
As both @steven.daprano and myself have mentioned, there are fundamental reasons (linked above and briefly discussed here) why the syntax is incompatible with the basic grammar of Python. At the minimum, there needs to be compelling real-world use cases that would justify the change, and a syntax and parsing grammar that would overcome the issues raised in past attempts. At this point, it seems rather unlikely to gain widespread support, but welcome to propose such.