Both clients and servers have to support both the X name and the regular name for decades, and servers have to deal with questions like "What if both are present but different?"
Sending two headers seems fine in most cases.
These are certainly downsides but hardly dealbreakers. On the other side, not prefixing has its own pros & cons, which seem more difficult to work around:
1. The obvious clash issue. If two pieces of software implement entirely different X-Value: headers, the standardisation effort clarifies the signal in the form of an unprefixed version. If both competing software applications start out unprefixed, the signal will always be ambiguous.
2. Implementation changes. If any lessons are learnt during initial use of a prefixed header, these can be applied by standardising on a slightly improved unprefixed version.
oops, you just enabled smuggling where there's a mismatch between what a proxy/firewall/etc supports and what an internal service supports.
X-Do-Evil: true
Do-Evil: falseThat's not a reason not to consider it a threat vector when implementing, but no more than when implementing any header (that interacts with another)
You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.
But the header wouldn't have interacted with another header if we hadn't decided to do this X-prefix nonsense!