This reads to me like a shortfall in Lucee, in two ways:
• there's no good reason to not follow CF here. Not doing so just creates situations like yours,
@jc
• The RFC is uncharacteristically lose when it comes to encoding form values, but it does indicate it's a thing that ought to be considered when passing non-US-ASCII data in the value. It falls should of using the usual "SHOULD" / "MUST", and just uses "can".
https://httpwg.org/specs/rfc9110.html#fields.values.
Lucee's approach requires the CFML dev to hand-crank the encoding of fields, where CF's approach takes care of it. I think CF's approach is the more CFML-idiomatic approach to the issue.
Looking more into it, there is an open issue in Jira relating to this:
https://luceeserver.atlassian.net/browse/LDEV-2250, but it's raising an issue about the encoding always being ON with Lucee, and no way to disable. I wonder if someone unthinkingly went "I know how to fix this, I'll just switch it off and remove the option to switch it on"..? I can't be arsed finding the relevant bit of source code and looking at its history. Does seem like Lucee is not intentionally diverging from CF here, just its changes haven't been very... erm... mindful.