Labelled arguments without a mandatory call-site constraint

Gleam's labelled function arguments let library authors present more descriptive names at the call site than the underlying parameter names. The intended benefit is clearer, more self-documenting client code, particularly for functions with several parameters or boolean flags. However, the compiler currently accepts both labelled and positional forms at the call site without emitting a warning, and there is no documented syntax, compiler flag, or configuration setting to mark labels as mandatory.

This leaves an unresolved boundary for API design: a library author can express preferred call-site conventions but cannot enforce them at compile time. Because labels do not affect function identity, currying, or higher-order function passing, the omission of a label is indistinguishable from a labelled call in every other respect. The behavior is consistent across Erlang and JavaScript targets, though future language versions could introduce stricter rules.

Assuming current stable Gleam behavior, is there any existing mechanism—documented or experimental—to require callers to use labels? If not, what is the recommended pattern for signalling that positional calls are discouraged without relying on external linting or documentation? Could a future compiler version make previously valid positional calls brittle?