Summary of the new feature/enhancement

PowerShell's elastic syntax (matching by unambiguous name prefix) is great for interactive use, but should be avoided in scripting.

Calculated properties currently employ elastic syntax:
Specifying a calculated property with single-letter key names - e.g., @{ n='prop'; e = { $_.val + 1 } } - is convenient, but lacks longterm stability, because n and e only unambiguously resolve to name and expression as long as no other keys starting with n or e are supported.

If n and e were officially declared aliases of name and expression an exact match for which would be considered unambiguous, the stability problem would go away.
Similarly, aliases should also be defined for all other currently supported keys: formatstring (f), label (l); width (w); alignment (a); ascending (asc); descending (desc).

With these aliases locked in, adding keys in the future would not break existing code.

This would be akin to the concept of parameter aliases (e.g., -ov for -OutVariable, -lp for -LiteralPath, or -c for -Command in the CLI).

Proposed technical implementation details

The internal HashtableEntryDefinition used to represent entries in hashtables defining calculated properties already has a SecondaryNames property that effectively amounts to aliases (it's already used to make name and label synonymous).

However, the IsKeyMatch() method must be amended to give precedence to (case-insensitive) full key-name matches among KeyName and SecondaryNames.