I don't understand the intro to the motivation section: I think it is accurately describing a problem which exists when you have this feature but it is describing it as a problem with the current language, which I don't understand.

Local variables and parameters aren't in scope outside of the library where they are defined, so privacy doesn't come into > play. Except, that is, for named parameters. A named parameter has one foot on each side of the function boundary.

There's nothing unique to named parameters about this. This is simply what it means to be public API. All class members (and classes for that matter) have "one foot on each side of the boundary" in this manner (that is, they are both an external reference, and an internal reference).

A public function containing a named parameter whose name is private raises difficult questions.

No more so than a public class containing a field whose name is private. It is true that you must decide on what the meaning of that is: we have done so. Now we propose to change it.

In general, I don't really disagree with anything being said in this section, but the framing is really confusing, because it frames this as something odd and different about named parameters in existing Dart, which I don't see at all and which I think distracts from the core direction of the discussion.

I would suggest rephrasing this away from the "named parameters present a puzzle" framing, to one of just "this is how things work now", e.g:

Dart uses a leading underscore in an identifier to make a declaration private to
its library. Privacy is only meaningful for declarations that could be accessed
from outside of the library: top-level declarations and members on types.

Local variables and parameters aren't in scope outside of the library where they
are defined, but named parameters can be referenced from outside of the library. This raises
the question of how to interpret a private named parameter:

test({String? _hmm}) {
  print(_hmm);
}

main() {
  test(_hmm: 'ok?');
}

Should this be allowed? And if so, do we treat this as a named parameter which
can only be called from within the defining library?

The language currently resolves this by saying that it is a
compile-time error to have a named parameter with a private name. Users must use
a public name instead. For most named parameters, this restriction is harmless.
The parameter is only used within the body of the function and it is idiomatic for
local variables to not have private names anyway.