There is no alike code in production, which is obvious if you read the proposal in good faith. If you can find a real world use case that is impacted, the autho

There is no alike code in production, which is obvious if you read the proposal in good faith. If you can find a real world use case that is impacted, the authors are keen to understand it. The examples you share are in the proposal discussion, so there is little value in rehashing your apparently bad-faith argument here. It's not a breaking change if nothing breaks. Go is and has always strived to be pragmatic. This is an incredibly pragmatic approach to solving a real problem. Being pedantic about this actually breaking a theoretical program which either makes no sense or doesn't exist does not add value to a proposal which already addresses this concept very well from the onset.