Unicode and "fitted"

Unicode defines specific ranges of codepoints as Private Use Area. These are codepoints for which Unicode does not provide any standardised character assignments, and which can be used by anyone for any purpose. This means, of course, that PUA codepoints have no stable interoperability: the same codepoint may be used in different fonts for different characters and hence produce different glyphs when switching between fonts. PUA codepoints are not recognised by shaping engines so do not participate in OpenType Layout except, in some software, as defined for a DFLT script tag; they will not interact cleanly in layout processing with characters and glyphs that have standardised script properties, e.g. you couldn’t give a glyph a PUA codepoint and expect it to interact with Devanagari or other characters that rely on complex shaping. The other major issue is that all PUA codepoints have a strong left-to-right directional property, so they can’t be used for right-to-left writing systems except with higher-level direction controls.

PUA does provide direct access to glyphs in text environments that do not support advanced glyph processing, but with major caveats. So, for example and as you have noted, some fonts assign PUA codepoints to smallcaps, and this enables users to access smallcap forms in environments that do not support the OpenType Layout c2sc and smcp features. But note that if users do this, they are breaking the text of their documents, because those PUA codepoints are not mapped to the upper- or lowercase letters, so text using those codepoints cannot be indexed, searched, sorted, or spell-checked. Whenever possible, use of PUA should be avoided, and GSUB or similar glyph processing mechanisms used instead.

I only ever include PUA codepoints in fonts for things like custom symbols, e.g. a client logo, or to support character variations in software that does not provide access to appropriate OTL features. A good example of the latter is Athena Ruby, which uses character variant features (cvXX) as the preferred access for the many forms of each letter, but also maps these forms to PUA for use in software that does not support those features. I don’t assign PUA to things like smallcaps, numeral variants, or ligatures, because their use in text should be discouraged.

For reference, the PUA codepoint ranges are U+E000..U+F8FF, U+F0000..U+FFFFF, and U+100000..U+10FFFF. You will sometimes see a portion of the first of these ranges identified as the ‘corporate use area’, where companies, e.g. Adobe, may have defined some mappings used for internal interoperability at some stage. Unicode does not define a corporate use area, though, and technically all PUA codepoints are equally unstable. Some companies that used PUA mappings historically, during the transition period from 8-bit custom encodings to Unicode and OpenType, stopped using them when better mechanisms became widely supported.

End-User-Defined Character is a Microsoft term for a set of PUA codepoints for which the Windows registry provides some hard-coded behaviour for specific system fonts.

I don’t know what this means, except that it may be particular to your tool. Different tools provide different ways to manage glyph sets, as well as different ways to manage character codepoint assignments to glyphs.

Some user software, e.g. the glyph palette in several Adobe apps, may expose the internal glyph ID ordering of a font to users, and because of this I like to manage my glyph order explicitly in each project, so that the result is intuitive for users to find their way around. Unicode character order is not always the most intuitive ordering, especially if you have a font that includes script extension characters from mutliple, non-adjacent Unicode blocks, or if the Unicode order of a script does not correspond to the order normally used by the target linguistic community (this happens, for example, for some Indic scripts).