At the moment I'm somewhat torn on this proposal, but rather more against than for.
On the negative side, the idea that from now on the compiler will constantly be trying to return almost everything I ever write feels to me like a pretty big difference to the language. Without having experienced this feature first-hand it sounds both annoying and stressful (and yes, also convenient for temporary print statements and multi-statement branches of if/switch expressions). The annoyance would come from the constant error message informing me that my latest expression isn't of the correct type, and the stress would be in contexts where the return type is quite permissive (as discussed above). I haven't seen much in the way of assurances that this won't generally worsen error messages and build times.
On the positive side, it would solve the current issues with multi-statement if/switch expressions and I think that it might ultimately prove itself to me to be a natural and ergonomic extension of the language that I use all the time and am glad was pushed forward against my resistance.
I share @JuneBash 's feeling that I wish I could try it out for a while first. I don't feel that my imagination will give me an accurate sense of how it will be in reality.
I was and am very unconvinced by the word then as the keyword, but then very late in the game in the last thread the word bind was suggested which I liked a lot better. Again though, to me it seems possible that this pitch could prove itself to be a beautiful extension of Swift's ergonomics, in which case I would be sad that I didn't see it at the time and instead we got saddled with a new keyword.
I think I'll (re-)bring up a rather different approach to solve the problems at hand, but I'll do that in a separate post so that anyone who shares my sentiments here can like this post without seeming to endorse the alternative approach.