The interesting part to me with this, is that for the last 20 years or so there's been a certain strain of C++ development, spurred on by increasing template/meta-programming support, that have advocated for moving more code to non-member functions, to benefit from improved reuse.

But this has been awkward because it means calling conventions may often be different and functionality that's "mixed in" this way seem far less integrated than functionality that's brought in via inheritance. It's also had the disadvantage that if you ever suddenly needed one of those free-standing functions to depend on internal state of an object, you'd either have to break encapsulation, or break the API (by moving the function into the class), or provide a legacy function to forward to the new API.

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".