In classical TeX a number of math mode fonts are used to supply the output glyphs based on the input, and as observed in the question the relevant \mathcode of the input token. In contrast, when using a Unicode math mode font only one font is used to supply all of the glyphs. As such, rather than the limited number of slots available in a TeX font there are large number of math mode-specific entries in a Unicode font.
Both Unicode engines (XeTeX and LuaTeX) provide the primitive \Umathcode for setting the extended math codes required for this to work. Details are available in both the XeTeX and LuaTeX manual: the syntax is
\Umathcode ⟨char slot⟩ [=] ⟨math type⟩ ⟨fam.⟩ ⟨glyph slot⟩
Notice that there is a requirement to supply a family here but that these will all be the same.
To set up the font dimensions required for math mode working, the engine or a suitable loader has to read the table supplied by the font. In XeTeX this happens as part of the (extended) \font primitive, for example
\font\lmmx = "[latinmodern-math.otf]/OT:mode=base;script=math;"
whilst in LuaTeX a Lua-based loader is required to extend the \font primitive (which out-of-the-box is identical to that in TeX90) (Realistically the font loader to use with LuaTeX is luaotfload, which is based on that written for ConTeXt but loadable with plain, LaTeX, _etc. There is work ongoing to use the HarfBuzz shaper with LuaTeX but this is not at present usable to my knowledge.)
As only one font is in use, conversion between input and output glyphs requires some differences from classical TeX. For example, input such as
$y = mx + c$
will not give italic letters unless they have the correct \Umathcode to point to the 'correct' codepoint. For example, we need
\Umathcode `\y = "7 "1 "1D466
(I'm assuming that we will use font 1 for all glyphs: this is not required.)
Operators in Unicode math are scaled by the font shaper directly rather than needing extensible parts. As such, something like \int is defined for Unicode use by
\let\int=∫
with the correct math code then chosen
\Umathcode `∫= "1 "1 `∫
Both XeTeX and LuaTeX have the \Uradical primitive for radicals: LuaTeX also has \Uroot.
An important consequence of using only one font is that for example making symbols bold requires that all of the relevant math codes change. Thus setting up something \bf requires that we map over all code points affected and alter their \Umathcode.
Whilst only one font is required, it is necessary to define math families two and three to satisfy the engine that sufficient math parameters are available. (This may change, certainly in LuaTeX, as it seems to be a hold-over of code paths from TeX90.) At the same time, script fonts need to be loaded telling the loader what they are. This leads to a minimal font loading set up something like
\font\lmmx = "[latinmodern-math.otf]/OT:mode=base;script=math;" %
\font\lmmvii = "[latinmodern-math.otf]/OT:mode=base;script=math;+ssty=0;" at 7pt %
\font\lmmv = "[latinmodern-math.otf]/OT:mode=base;script=math;+ssty=1;" at 5pt %
\textfont1 = \lmmx
\textfont2 = \lmmx
\textfont3 = \lmmx
\scriptfont1 = \lmmvii
\scriptfont2 = \lmmvii
\scriptfont3 = \lmmvii
\scriptscriptfont1 = \lmmv
\scriptscriptfont2 = \lmmv
\scriptscriptfont3 = \lmmv
(Again, I am assuming XeTeX font syntax here.)
As noted in comments, there are a large number of additional font dimensions in Unicode math fonts. LuaTeX gives these names (all listed in the LuaTeX manual), whilst for XeTeX they have numbers and are accessed using \fontdimen.
The TeX90 primitives \delimiter, \mathaccent and \radical all have extended Unicode versions: \Udelimiter, \Umathaccent and \Uradical. Unlike the TeX90 versions, \Udelimiter and \Uradical do not need to point to multiple glyph slots: only one slot is needed and the font shaper is responsible for growing the glyph as required. The syntax of \Umathaccent is significantly extended compared to \mathaccent, certainly for LuaTeX. All three primitives are described in the LuaTeX manual and to a lesser extend in the XeTeX one.
Don't use \outer it never does anything useful (despite the fact that I use it in the bm package:-)
"High speed" here means when TeX is tokenizing input without evaluating it. So for example in plain TeX
\def\foo{...\newcount\abc \abc=42 ...}
You get an error as the replacement text of \foo is being collected, as \newcount is outer in plain.
lots of macros reasonably want to embed \newcount. eg a \newthorem construct probably needs to allocate a theorem counter. The plain TeX version has to use contortions like \csname newcount\endcsname just to avoid the outer \newcount token, which is outer just to discourage use of \newcount in a macro that is used often, in a way that would allocate a counter on each use, and run out of count registers.
Best Answer
This is not really recommended. Anyway, here a technical solution: In this specific case you could change
$to be an active character (i.e. like a macro) which holds an old normal$. Then two$s in a row would not be combined:All
$$inside previously defined math environments are still OK because they hold the dollars in their original category code.However, I would recommend the following solution instead: To write your two equations simply write
$equation1${}$equation2$or$equation1 equation2$. If you don't use$$in your apparently automatically generated code then it should be safe to search&replace all$$with${}$.