I confirm it with

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 77a535285f0fd5f2464430abdc67cf99be024868
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-23_23:04:23
Locale: de-DE (de_DE); Calc: CL

1. I used highlight color Light Blue 4 (from standard palette)
2. Saved as .doc
3. Reopened document. Highlight color was blue (#0000FF)

Quote from: https://bugs.documentfoundation.org/show_bug.cgi?id=97865#c9

This thing happens because MS highlighting has only 15 highlighting color and when you save Writer text background \ highlighting to an MS format it is converted to this color palette.
It's the default behavior, but you can change this at Tools -> Option -> Load/Save -> Microsoft Office, to save Writer text background as MS Shading and so colors won't change. Nut in this case when you open that *.doc file in MS Word you could not change the text background with highlighting tool, but with the shading tool:
https://blogs.technet.microsoft.com/hub/2011/04/05/how-to-select-more-highlight-colors-in-word/

Before the 5.0 version sometimes we saved Writer text background as shading (doc, docx), sometimes as highlighting (rtf). From that version an option is added, so the user can select the preferred behavior. Highlighting became the default, because on LO UI text background is called highlighting. This option can be set also via user profile.
https://wiki.documentfoundation.org/ReleaseNotes/5.0

So, probably not a bug..

Has UX any opinion on this? The type of issue has been reported multiple times...  all of them where closed with the explanation given in comment 2. (see bug 96016, bug 97865, bug 113872) However it doesn't feel right...

It's might be better to switch the setting the other way around -> saving the highlighting as MS Shading. 

Pro
* It would prevent unexpected dataloss (in the sense of losing highlighting)
* it's compatible with MS Word (viewing)
* People aware of the risk of switching to MS highlighting mode (mouse over text?)

Contra
*It will break the experience of MS Word users wanting to edit a file..

Switching to the save mode makes sense. Guess most users don't know the difference.

Alternatively, we could ask the user when exporting a document may result in corrupt properties.

Microsoft only allows 15 colors to be used as highlight colors in both .doc and .docx, so this is a format limitation bug that isnt ours.

(In reply to Telesto from comment #3)
> Contra
> *It will break the experience of MS Word users wanting to edit a file..

Users being able to modify the highlighting is the most important thing, so i'd stick with this by default.

(In reply to Heiko Tietze from comment #4)
> Alternatively, we could ask the user when exporting a document may result in
> corrupt properties.

We already give users the 'Confirm File Format' dialog when not saving to ODF, which does state 'This document may contain formatting or content that cannot be saved in the currently selected file format'. We could go beyond this, if devs are interested in implementing it, and create a dialog similar to the MS compatibility checker.

http://technastic.com/wp-content/uploads/2016/02/Microsoft-Word-Compatibility-checker.jpg

(In reply to Yousuf Philips (jay) (retired) from comment #5)
> (In reply to Heiko Tietze from comment #4)
> > Alternatively, we could ask the user when exporting a document may result in
> > corrupt properties.
> We already give users the 'Confirm File Format' dialog when not saving to
> ODF, which does state 'This document may contain formatting or content that
> cannot be saved in the currently selected file format'. We could go beyond
> this, if devs are interested in implementing it, and create a dialog similar
> to the MS compatibility checker.
> 
> http://technastic.com/wp-content/uploads/2016/02/Microsoft-Word-
> Compatibility-checker.jpg
This would be really genius to have a list of things that change instead of a vague statement that something could happen--or not.

In such a dialog also the possibilities in the options dialog can be referenced because nobody finds the option to change highlighting saving today.

*** Bug 116458 has been marked as a duplicate of this bug. ***

The bug is still active in the latest version of LibreOffice:
Version: 6.2.2.2 (x64)
Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: en-CA (en_US); UI-Language: en-US
Calc: CL

I will highlight a passage with "Blue 1" for a Writer .docx format. I will save it, and close Writer, and then I open it again, and the highlighted passage will now be "Blue 3".

I tried it with another colour and I chose "Cyan 8" this time, and I saved it, and opened it up again, and this time it was #008080.

Since this is the result of a MSO limitatin (see comment 2), the discussion in cemments 3 - 6 is about how to deal with such limitations. So my question is: Should we close this bug (and open a new one with the mor general topic of comment 3-6) or rename the bug summary?

(In reply to Dieter Praas from comment #11)
> Should we close this bug or rename the bug summary?

Either way we have to come to a conclusion. I like the way it's done by MSO (see c5) - but it's a question to devs. So needsDevAdvice.

I submitted a similar request some time ago, see bug 104822

I also started working on such a list on the wiki (work i progress due to time constraints): https://wiki.documentfoundation.org/User:Kerwyn/informationoncompatibility

Heiko, I think we should close this as duplicate of bug 104822. Do you agree?

I brought it up in the ESC call yesterday

   * List incompatible features when saving to alien formats in detail
     + https://bugs.documentfoundation.org/show_bug.cgi?id=115291 
     + prototype for solution in c5; feasibility unclear
     + trad. answer is – better to fix the interop problems (Michael)
         + 15 highlighting colors doens’t go to MSO (Heiko)
             + why do we have so many ? (Michael)
         + its lots of work scanning the doc to find problems (Michael)
         + two sides – better to spend energy supporting (Miklos)
             + on other side – the CSV filter “only current sheet”
             + some merit to this.
             + in the past did have some scanner code to detect
                 + this was removed.
         + remember the filter collection / warning (Caolan)
             + back in the day – more effort to detect missing than impl. It
             + perhaps for big features works, but micro-level tricky.
             + PDF export has something like this too.
AI:  + drop chunk into the bug & send to QA (Heiko) 

I suggest to resolve this request as WONTFIX. 

The link to compatibility setting is not a big deal though also not really helpful. But I wouldn't make it a duplicate.

(In reply to Heiko Tietze from comment #15)
> I suggest to resolve this request as WONTFIX. 

Additional suggestion: Perhaps it is possible to collect incomtable features in a wiki-page or something like that and add a link to that page in the warning-message.

(In reply to Dieter Praas from comment #16)
> Perhaps it is possible to collect incomtable features
> in a wiki-page or something like that and add a link to that page in the
> warning-message.

I'm afraid such a page is not really accessible. It might be good for odt vs. doc (would be a nice comparison sheet, btw) but if you save as rtf, txt or whatever almost every feature is not existent. Adding Italo since the format comparison was always his topic. The idea is to have a (large) sheet with supported features that gives an overview of the interoperabilty (wouldnt be surprised if we have something like this).

(In reply to Thomas Lendo from comment #6)
> (In reply to Yousuf Philips (jay) (retired) from comment #5)
> > (In reply to Heiko Tietze from comment #4)
> > > Alternatively, we could ask the user when exporting a document may result in
> > > corrupt properties.
> > We already give users the 'Confirm File Format' dialog when not saving to
> > ODF, which does state 'This document may contain formatting or content that
> > cannot be saved in the currently selected file format'. We could go beyond
> > this, if devs are interested in implementing it, and create a dialog similar
> > to the MS compatibility checker.
> > 
> > http://technastic.com/wp-content/uploads/2016/02/Microsoft-Word-
> > Compatibility-checker.jpg
> This would be really genius to have a list of things that change instead of
> a vague statement that something could happen--or not.
> 
> In such a dialog also the possibilities in the options dialog can be
> referenced because nobody finds the option to change highlighting saving
> today.

(User and Bug Reporter here)
I've confirmed that this issue is due to the .doc and .docx file format that I've saved my files in because when I saved the file in .odt there's no problem with the colour changes. I only really saved my documents in the .docx format for university, so I don't have a need to use that format now, so I'll be using .odt from now on.

If a user changes the save as format to be .doc or .docx, rather than just give a dialogue that there could be some incompatibility in saving it to that specific format, is it possible to actually block out the extended colours that are available for the .odt format? So, in this instance, I've set my default save format to be .docx, and so LibreOffice will only show the colours that the MSO will allow, and thereby preventing me from choosing other colours that will just change back to the default MSO colours. The program is already doing this once I use the .docx format, so would it be too difficult to block off everything that isn't MSO for the colour palette? And if this is possible, then perhaps the program could go into a "MSO Compatibility Mode" and even show it somewhere on the program, where everything would change to be compatible with MSO and block off options that work with .odt, but won't in MSO's formats, so that user, especially inexperienced users, won't have to even worry about incompatibility?

I should point out that even with different versions of MSO there are colour palette issues, so it's not just with LO, but within MSO itself. This is one of the reasons I've been MSO free for years.

Thanks for putting out a fantastic office suite!

(In reply to Roeland from comment #13)
> I submitted a similar request some time ago, see bug 104822


IMO it's most logic to keep this bug 115291 in it's original sense, and link
to 104822 as a META-issue.

> I also started working on such a list on the wiki (work i progress due to
> time constraints):
> https://wiki.documentfoundation.org/User:Kerwyn/informationoncompatibility

Still lots to do :)
You may want to ask on users@ or QA@ lists?

Creating such a list is a hell of a task, given that OOXML as a document format is not consistent even within the same release of Microsoft Office. We will add the list to the documents generated by the soon to be announced ODF Advocacy Open Project at OASIS.

Added Marina Latini, as she will be co-leading the ODF Advocacy Open Project.

*** Bug 68489 has been marked as a duplicate of this bug. ***

See also bug 92256 comment 19:

> I don't like the current "alien format" warning dialog. It misses
> transparency. As a user I would like to know, which exact features of my
> current document will be lost during export. I think I once saw that MS
> Office showed me a dialog with a list of features that will get broken
> during export into an "old format" like rtf. If we had such list in
> LibreOffice, too, It would be easy to add a new list entry like "your
> formula syntax for string references is changed to EXCEL A1, please check
> your strings". This is what I would expect if I export into an alien format.

Bug 125268 comment 37 (and below) are also related.

So the current "List incompatible features when saving to alien formats in detail" title of this bug (which, curiously, doesn't fit well with the actual discussion here - except for c#5, making the final rename of the issue quite questionable - should it had been closed, and a clear new issue created?) has many proponents.

*** Bug 154208 has been marked as a duplicate of this bug. ***