So far, MS Office 2007 was doing everything I needed, so I did not feel the need to move on to a newer version.

But, yes, it is time to move on.

It was the same with Windows; I went straight from Win XP SP3 to Win 10.

You are right - I thought I saw in your doc that body_base was based on Normal but it is actually based on no style. Still, in my mind, this is just an additional level of complexity that adds no value because you already understand how styles are chained together. You say you can tweak your base style to change all of the related styles. Yep Equally you could do the same if your children styles were based on Normal. As long as you understand style hierarchies, you can configure your styles to best suit your work patterns. But you don't NEED to add artificial complexity.

I wouldn't expect that upgrading Word is likely to resolve the issue you are seeing. Certainly, when I looked at your document in Word 2016 I could see the issue that you put in it so using a newer version of Word is not resolving the phantom markup already in the document. It is possible that a newer version wouldn't INTRODUCE the problem while you are making tracked edits but I would be surprised if was different to earlier versions of Word.

In my experience, the evolution of Word's underlying behaviour is extremely minimal. Each newer version of Word changes the graphical user interface in large or small increments but the underlying functionality rarely changes.

I just thought of a simple change your could make to your document to mask this bug and hide the fact it is still there. What you are seeing is the text colour of Accent 6 is being added to the text. You notice this because this colour is NOT black - so the simple fix is to change the Accent 6 colour so it is Black. This change will not stop the bug but it will make it so no one notices it.

At some stage, AFTER your revisions are accepted/rejected and you want to do a quick cleanup to remove the remnants of this bug - you can run the command to remove all local font formatting WHILST retaining character formatting.

There are two commands to remove font formatting. The obvious Font Reset (Ctrl-D) command also gets rid of character styles so you need to avoid that one if your document intentionally uses character styles. The non-obvious vba command that retains the character styling but gets rid of other font changes is

__________________
Andrew Lockton
Chrysalis Design, Melbourne Australia

Thank you, Andrew, for the workaround and for the suggestion for cleaning up with the vba command.

I will keep in mind that “it is possible that a newer version wouldn't INTRODUCE the problem while you are making tracked edits.”

You have written: “Equally you could do the same if your children styles were based on Normal.”

I was under the impression that the “normal” style was dependent on the Normal template.

And there is no guarantee that any two installations of MS Office will have the identical Normal templates.

That I why I defined my base style based on “no style.”

The Normal style is definable just like any other style. It isn't dependent on any particular template BUT if you choose to import/refresh styles from any template then it is likely that the Normal style will be updated - that is the point of importing styles after all.

Just make sure that importing of styles doesn't happen when you don't want it to. This means you should never tick the option in the Templates and Add-ins dialog to "Automatically update document styles" since this refreshes styles every time you open the doc (and other users may have different templates).

As I said, this is really no different with your own custom styles - if you choose to import styles from a template, and that stylename exists in the template, then that style definition may change. The Built-in styles always exist in every template whereas the custom styles might exist in a template.

__________________
Andrew Lockton
Chrysalis Design, Melbourne Australia

Okay, thanks, Andrew.