(This is an issue I'm experiencing in the context of importation of PDFs, but I actually think it's more generally relevant.)

Some font families have names which are sequences of multiple words, e.g. Adobe's "Minion Pro" (an OpenType version of their Minion PostScript font). But such sequences often someone get mangled into no-spacing character sequences, e.g. "MinionPro". There are probably multiple reasons why this can happen; quite possibly something to do with input filters for file formats, but maybe already in the file being opened. Anyway, this happens.

So, it is not uncommon for LO to open a document which has a font of the  "FooBar" family, while the system has font of the "Foo Bar" family - or even vice-versa: The document has "Foo Bar", your system has "FooBar".

I believe that in these cases, and when an exact match of the family name is not found, LO will, fall back on the spaces-on or spaces-off alternative respectively. 

There are probably multiple places in the code where this heuristic could be applied. Obviously within input filter code, but also when you "just" open an ODT, in choosing which font to display with - so something like an implicit font substitution rule? Let developers decide. 

PS - It's not even a search for a lot of font family name combinations: Just one extra combination for removing spaces, and as many combinations as there are capital-separated words, i.e. FooBarMS would make us look for:

FooBarMS,

FooBar MS, Foo BarMS, FooBarM S,

Foo Bar MS, FooBar M S, Foo BarM S

Foo Bar M S

although maybe we could be more conservative with that.