Thank you for reporting this issue! I have been able to confirm the issue on:
Version 3.6.5.2 
Platform: Bodhi Linux 2.2 x64
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well.

Marking as:

New (confirmed)
Minor - easy enough to change the font back, the format isn't standard so not affecting a lot of users, not preventing high quality work, on initial inspection it's fine, only if you need to edit the formula again

Low - default seems accurate in this case



+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material

Tested with Version: 4.3.4.1
Build ID: bc356b2f991740509f321d70e4512a6a54c5f243

and also with Version: 4.4.0.0.beta1
Build ID: 9af3d21234aa89dac653c0bd76648188cdeb683e
Locale: ru_RU

The bug still persist, but the cached correct initial view is no more kept.
So, the problem is worse now.

The Flat XML ODT format is a standard format, that is, although not very common, still very useful in case when recoverying a corrupted file.

Now, if a file contain many formulas, they all become distorted at document opening (and even corrupted, if default font doesn't include some symbol that was used). This will make using that file very difficult.

I raise the importance to medium/normal. Hope that this is appropriate given the new behaviour.

Can you give an example file showing the corruption that you mentioned? If we can get confirmation that there is actual corruption then we can bump it one higher to major - high, but i prefer not doing this until we actually have an independent QA person saying they've seen corruption.

Thanks

I actually would rather it be at Major -> Medium as flat XML is not a common format at all (therefore this is unlikely to affect a lot of people). Additional proof is that nearly 2 years have passed and we have no one else commenting on the bug and no duplicates.

Created attachment 110393 [details]
Formula->fodt test

This attachment contain a TTF font and two text documents, which contents is just one formula object. Also, screenshots are included.

The font is used in our organization as stangard for engeneering drawings, calculations and documents. Its use is mandatory to guarantee consistent look of our documentation. It contain some non-standard character in private area, that correspond to Russian GOST symbols.

The formula in document simply contain those characters. In original (ODT) document, if the font is awailable in the system, the characters are OK. It is apparent on formula-odt.png. When exported to FODT, on reopening the formula becomes "corrupted" (see formula-fodt.png).

Please note that no data loss in formula happened; if the font is restored manually, it will be OK again. But (1) the process may be very time-consuming with big documents with many formulas, and (2) there may be situations when either correct font is unknown, or a formula is overlooked. Thus, the result may be wrong. So, missing font information still may qualify as data loss...

Still reproducible with Version: 5.0.4.2 (x64)
Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78
Locale: ru-RU (ru_RU)

Still reproducible with Version: 5.3.0.1 (x64)
Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-US (ru_RU); Calc: group

Perhaps we should raise the importance to critical, it's on an ODF format.

(In reply to Mike Kaganski from comment #0)
> If a formula has some customized font settings, then these settings are lost
> upon saving the document as Flat XML. This happens both in documents (.fodt)
> and in spreadsheets (.fods)
> 
> Steps to reproduce.
> 1. Create a new empty document.
> 2. Insert->Object->Formula...
> 3. Type "a"
> 4. Format->Fonts... See that Variables are set to Times New Roman, Italic
> 5. Modify->Variables
> 6. Select Arial -> Ok -> Ok
> 7. See that the font of the formula is changed.
> 8. Save as a .odt, close and reopen to check that the settings persist
> (enter the formula and check the settings).
> 9. Save as a .fodt, close and reopen.
> 
> Expected results:
> The font modifications should stay.
> 
> Actual results:
> Initially the formula is shown correctly, but when opening it for editing,
> the font changes to Times New Roman and the settings in Fonts dialog are
> back to defaults. The initial correct display is possibly due to cached
> metafile of the formula.

After performing a clean reinstall from 5.2.2.2 x64 to 5.3.0.3 x64, the results have changed:
1) The repro steps are better now: the ODT where the small A was written preserved the font as italic Arial, but the FODT uses the default italic Liberation Serif and Liberation Mono.
2) In the attachment: the ODT preserved all the font changes and looks just like the pic. The FODT switched back to the defaults of Liberation Serif, Liberation Mono and the italics, and is the exact same mess as in the pic. When double-clicking the formula in the ODT, it presents the same kinda mess in the formula box on the bottom of screen as you see immediately in the FODT. The box does track each character successfully in that wherever you move the keyboard cursor it highlights the corresponding symbol on the document in both FODT and ODT.

Unfortunately no.

1. The repro steps aren't any better, exactly as you described it. The ODT has always kept the font information, as it is now (see my repro step 8 in comment 0 - "check that the settings persist"). And FODT still looses the data.

2. The attachment contains, among other files, the required font, without which the display both in FODT *and* in ODT will be wrong. That is explained in comment 5.

Still reproducible with Version: 6.0.3.1 (x64)
Build ID: 62abb169b0efa1520d7bee1f586865354060b989
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL

Regina: could you please advise on this? I don't see a "flat" filetype for the Math documents; so I cannot understand how should be the export implemented properly...

Each Math-object is a separate document in the packed file format. As such it has its own settings.xml. Currently this settings.xml parts are dropped totally in flat format. The flat format has only one <office:settings> element, and this contains the settings for the surrounding document and none of the settings for the Math-objects.

There are several solutions possible:
A Extend the <office:settings> element
B Convert the Math-objects settings into CSS styles and put them into the <math> element
C Change the way a Math.object is embedded from the nesting <draw:object><math> to <draw:object><office:document>...<math> for flat file format

I personal would prefer B, because that is the only way to write MathML in a way, that allow other applications to show the formulas as intended by the author. It should be preferred in the long run. But because we currently still rely on "StarMath 5.0", and input of pure MathML still needs a lot of improvement, this might give a bad user experience in the short run.

Currently only LibreOffice itself writes flat format, so version A and C are both possible. Because all three ways mean a large change in document structure, I suggest to discuss it on the dev-mailing list, so that the audience is wider.

Looked once again: C would not help. But further option would be to put the settings into the <office:object> element in a loext: namespace.

(In reply to Regina Henschel from comment #16)
> Looked once again: C would not help.

Sorry: I don't see why? C is the way Spreadsheet embedding into text document works; there are <office:meta>; <office:settings>; <office:scripts>; ... etc, and finally, <office:body> with the spreadsheet itself, all inside <office:document>. Why can't it be reused for Math - and be better for consistency?

(In reply to Mike Kaganski from comment #17)
> (In reply to Regina Henschel from comment #16)
> > Looked once again: C would not help.
> 
> Sorry: I don't see why? C is the way Spreadsheet embedding into text
> document works; there are <office:meta>; <office:settings>;
> <office:scripts>; ... etc, and finally, <office:body> with the spreadsheet
> itself, all inside <office:document>. Why can't it be reused for Math - and
> be better for consistency?

In case of a spreadsheet you have the nesting <office:document> <office:body> <office:spreadsheet>. But <office:body> has nothing similar for Math, there exists not <office:math>. You need a <draw:object> as parent of a <math:math> element and a <draw:frame> as parent of the <draw:object>. But a <draw:frame> element needs a parent too, which would be a <office:text>, a <draw:page> or a <table:shapes> e.g. All together this means, that you embed a document, which in turn has a math-object embedded. So it is the same problem as now, only one level down.

If you would really write such structure, you would not be able to distinguish it from e.g. a Draw-document embedded in a Writer-document where the Draw-document contains a Math-formula.

I too was allured by then having an additional <office:settings> element.

Created attachment 140896 [details]
Some ideas for file format if using settings (see A)

I see the problem still in Version: 6.3.0.0.alpha0+ (x64)
Build ID: ccf3a0600ee902390ad6112ecf28223078bdd2db
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-13_03:08:59
Locale: de-DE (en_US); UI-Language: en-US
Calc: threaded

Created attachment 167339 [details]
Example of broken formula

Created attachment 167340 [details]
Broken formula in V7 fods file

I am experiencing this issue to with V7 of LO. I was really confused as to why this was happening to my spreadsheet as the program did not warn that I could experience a loss of formatting when saving to .fods

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Windows 10.0 Build 20175; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: CL

Yes, I agree the flat formats should never have loss of formatting!
This format is infact very useful for git versioning:
https://wiki.documentfoundation.org/Libreoffice_and_subversion
and formulas are important for tech doc.

As an example case, here is the Italian Fire Safety Code on Github:
https://github.com/codicepi/codicepi-edit

I confirm this bug is still in:
Version: 7.5.1.2 (X86_64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: it-IT (it_IT.UTF-8); UI: it-IT
Flatpak
Calc: threaded