Granular details. It turns out that the style of a merge field will prevail over a 'styled' field (from a related table), BUT NOT over the customised content of that field.
In normal development/ layout mode, you can easily see if a field has 'custom' rather than purely styled content, via the red triangles. IF, HOWEVER, the field's content has been changed at the user end, via Formats/ Fonts, there is NO indicator to show that the content is custom. Also, when you go into layout mode, there is no indicator that this content is now custom.
Thus, if the source field has been fiddled, i.e. customised, then the style of the merge field in the related table WILL NOT prevail over the attributes of the source. Conversely, if the source field is styled (but not customised), then the style of the merge field WILL prevail over the source's attributes.
Personally, I think this is a limitation of the generated CSS - it would be good if it was easier to track down the details. Example: user applies fonts that look identical to normal styling so that now the field behaves as a customised field rather than a styled field.
I use custom menus to change the Paste command to Paste plain text (without styles), and remove many of the Format menu options to keep users from embedding formats in the actual data. Too many things can go wrong in reporting when data contains its own format.
That's a good idea.
Given the realisation of the extent of style behaviour quirks, not just a 'good idea', but probably absolutely essential :-) To clean things up, not only did I need to replace the source field itself, I also needed to remove the data and then replace it. In this case it was straightforward because it happened to be a 'setting', but in another data context, it would have been a real pain.