>> This change would make it even more attractive to break out functionality that does not depend directly on the internal state of an object as standalone functions, in effect creating a sort-of "limited class re-opening".

You can already write the functions that way, nobody is stopping you. f(x,y) a function that returns something based on x and y. x.f(y) a method where object type x does something based on y.

The second form will have access to private members of x and has some notion of the object doing something. The first form implies that x is just an argument to the function.

What I see is C++ going from object oriented to functional - in other words following whats trendy.

That said, I think they should take all the lessons learned doing high performance implementations of C++ and start over to create a new language that doesn't suck with all the baggage.