Escape characters in MIF files

re: I.e. \xA0 and \u00A0 are regarded as the same character, right?

Probably not, and the example used for your conjecture shows why.

\xa0 is FM legacy hex code for dagger (†),
which is Unicode \u2020.

Unicode \u00a0 is non-breaking space,
whereas in legacy FM notation for that might be \x11
(and anything below \x20 is treated as Control, and may or may not map to a specific Unicode code point, or HTML named Entity on output).

Without having tested it extensively, my guess is that FM treats \x## notation as internal-only, and may* convert any that are displayable non-ASCII to Unicode on output.

There are a number of separate issues here, not all of which have obvious likely implementations.

When opening a pre-FM8 file in FM8 or later, most non-ASCII "Standard" characters must be converted to Unicode, because few (perhaps none) of them have hex codes/ANSI numbers that match their Unicode code points.

If a codepage (overlay, non-Unicode) font had been applied, changing the hex code might be destructive. This font overlay might be triggered by the Paragraph Format, Character Format or local Font override.

If I were writing scripts for FM these days, I have goal of favoring Unicode, and avoiding hex codes, where possible. And it might not always be possible, as for many in the \x00-\x20 range, for example \x15 (non-breaking hyphen), which has no Unicode equivalent (that has to be implemented with CSS). Heck, I'm not even sure that \x11 (non-breaking space) gets rendered as \u00a0 and/or entity {ampersand}nbsp;

* I say "may" because it remains necessary in the Unicode age to use codepage fonts in some cases, such as where no Unicode font exists for the typeface, or the entire character set has no Unicode codepoints (yet, maybe ever).

Think you may want to shoot this inquiry to Adobe Support - the forums are user-to-user.