Mike, thanks for your analysis in bug 99402, here's the new bug report as requested. Please adjust component if a different one is more suitable.

This problem is described as #6 in bug 39256.
As that bug looks more like a meta-bug for tracking WMF-related problems, I add it as "See Also" and will work on it here.

Further analysis shows that my previous statements need correction.
1. Always using 1252 doesn't work for Windows; I must had been dreaming when wrote that it worked under Win10. So, the only way to fix this by selecting encoding is conditional compilation (symbol charset for Windows, 1252 for Linux).
2. OpenSymbol doesn't contain necessary glyphs for brackets/braces/parentheses. Standard Symbols L actually does. When Symbol font encoding is set to 1252, Standard Symbols L is used by LO, while for symbol encoding, OpenSymbol is used, with recoding using utilities from unotools/source/misc/fontcvt.cxx. I see preferable way to fix this by enabling LO to substitute Standard Symbols L for Symbol font when symbol charset is used.
3. MT Extra problem mentioned above (and in bug 39256 #6) is fixed by using symbol encoding, works both for Windows and Linux (MacOS isn't tested).

It's not that straightforward to fix the font substitution.
The actual used font is selected in ImplFontCache::GetFontInstance() and PhysicalFontCollection::FindFontFamily(). The latter performs several steps, and on my system, it finds OpenSymbol as Symbol's replacement at rFontSubst.getSubstInfo( aSearchName ). There, it searches for exact match of searched name in sorted list. If it wouldn't find OpenSymbol here, e.g. by explicit break for Symbol search, then PhysicalFontCollection::FindFontFamily() will use next method: for symbol fonts, it uses LO configuration org.openoffice.VCL:LocalizedDefaultFonts['lang'].SYMBOL, that is a list of fonts: on my system, it is StarSymbol;OpenSymbol;Arial Unicode MS;StarBats;Zapf Dingbats;WingDings;Symbol. If I add e.g. Standard Symbols L to the head of the list, then "it works".

To fix it properly, I think, two things are necessary:
1. To update OpenSymbol (that is LO native font, and so it must support the necessary glyphs itself, instead of hoping that some system font will happen to have those). I wonder if just copying those glyphs from Standard Symbols L is OK? According to https://en.wikipedia.org/wiki/Ghostscript, the font is either GPL or AFPL.
2. The first step alone if not a proper fix: if user installs a font with a name that will intercept the search in the above-mentioned algorithm, then OpenSymbol won't be selected. So, some hardcoding may be necessary.

Posted a patch to gerrit: https://gerrit.libreoffice.org/28677

I managed to avoid using external fonts as source of absent glyphs, using and modifying OpenSymbol's own glyphs.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=56badc051ceee678e978add00d36c8e4d2d37ddb

tdf#101889: add absent brackets to OpenSymbol

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

@Mike, Khaled * 

So, just a thought here--not sure of the feasibility, or the work involved.

Could the scope of OpenSymbol be expanded, its encoding & format adjusted if needed--or a new font spun off to replace it in LibreOffice--that covers more of the Unicode SMP--including the BMP & SMP codepoints for Emoji that we have defined notation for use? And in process maybe expand glyph coverage for musical and mathematics notation.

With so many glyphs enabled now in the GUI we are missing coverage in a project deployed font--could some set of glyphs from Unicode be added to OpenSymbol to cover the glyphs we are defining as Emoji input in the autocorrect tables?

Similar issue in that OpenSymbol is hard coded for use in Math, but misses large chunks of otherwise useful glyphs for formula composition.

Also missing are most of the coverage BMP & SMP for musical symbols. Seems like they all would be well served with a reworked OpenSymbol font.

(In reply to V Stuart Foote from comment #6)
> Could the scope of OpenSymbol be expanded, its encoding & format adjusted if
> needed--or a new font spun off to replace it in LibreOffice--that covers
> more of the Unicode SMP--including the BMP & SMP codepoints for Emoji that
> we have defined notation for use? And in process maybe expand glyph coverage
> for musical and mathematics notation.

IMO, the OpenSymbol is a good place to all that stuff, but... that's a (font) designer's work. If someone volunteers for that, that would be great.

I’d not added any new characters to OpenSymbol unless we really have to, I actually think we should move characters from OpenSymbol (e.g. math, but this require bigger changes in Math) and keep it strictly for bullets and other similar things.

If we really need to bundle and emoji font, we can just use one of the existing freely licensed emoji fonts.

Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue

remains an issue