To be fair, how I imagine the transition going, named parameters on lower
level functionality will be implemented last. It's the higher level
libraries that will get more direct use and have more developers actively
maintaining the codebase and adopting the latest spec. At the same time, I
think demand for named parameters is going to be reduced amongst users
closer to the metal, e.g. the low latency community. That's just because
the parameter names aren't standardised and will likely never be
standardised, and unless I'm mistaken there's absolutely nothing stopping
e.g. the Linux maintainers from changing a function from one of their
parameter naming conventions to another.

Saying that, when it comes libraries made to conform to standards, the only
thing that really matters will be the declarations, so maybe some shadow
headers might be a quick fix. If the naming impacts definitions too, I'd
guess that means we're going to introduce optional naming into mangling - which
IMO would be a massive headache, but is also necessary for the obvious
proposal that will come along as soon as we have named parameters: "Allow
overloads with the same type signature but with different names".

As for the standards library, it's clearly going to be a major change, and
is exactly what I meant before when I said that library maintainers will
need time to prepare for their parameter names to be locked in. That's not
as trivial as it sounds - consistency in parameter names has never been a
problem, but if we're going to do this properly then every method in the
standard library will need to be checked to make sure names aren't
confusing or inconsistent. This sounds like pedantry, but it really isn't
if names are to be part of the interface.

>From this angle, it looks like an opt-in approach would make the most
sense. But that's not going to be popular with people who want to be able
to use it on everything from day 0. Something that might be rather easy to
get started with would be along the lines of deduction guidelines - so
people can wrap what they like, how they like, where they like, without
requiring the library maintainers to do it for them. It isn't a permanent
solution but it might be worth considering.

Declaration:

void lovely_function_name(char const* Nm bool is_registered, int AGE);

Wrapping:

lovely_function_name(
    char const* :name, bool :is_registered, int :age
) => some_lib::lovely_function_name(:name, :is_registered, :age);

Usage:

lovely_function_name(:name => "Bob", :is_registered => false, :age => 82);