(When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.)
Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm).
Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may still be character-based (e.g. Notepad++).
Some terminals try hard to both be monospaced and show you useful stuff, and will either horizontally truncate the glyph, or draw subsequent glyphs on top of any overflow (e.g. gVim).
Some terminals simply make a total hash of it, with the cursor positioning being monospaced, but drawing subsequent characters after the incorrectly-wide glyph (e.g. Ace).
Your example of U+FDFD is bonus fun because it’s RTL. Most terminals don’t handle RTL at all well. (Terminals capable of proportional rendering such as Notepad++ and plain old Notepad are much more likely to treat it properly in my experience.)
I can tell you that terminal emulator is finding the character in the fonts that I have configured it with. But it won't tell you the stuff about character widths that you want to know, I suspect.
As I mentioned, my terminal emulator uses bitmap fonts. Whilst bitmap fonts do have a mechanism of specifying either single-width or double-width characters, it ignores that and displays everything in the same width, rescaling everything with some slight special-casing of block graphic and horizontally repeatable characters. So whilst by the looks of the amount of detail in the glyph on screen, U+FDFD is a double-width character in the font file; it occupies a single column.
(When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.)
Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm).
Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may still be character-based (e.g. Notepad++).
Some terminals try hard to both be monospaced and show you useful stuff, and will either horizontally truncate the glyph, or draw subsequent glyphs on top of any overflow (e.g. gVim).
Some terminals simply make a total hash of it, with the cursor positioning being monospaced, but drawing subsequent characters after the incorrectly-wide glyph (e.g. Ace).
Your example of U+FDFD is bonus fun because it’s RTL. Most terminals don’t handle RTL at all well. (Terminals capable of proportional rendering such as Notepad++ and plain old Notepad are much more likely to treat it properly in my experience.)