It's very possible. Sounds almost identical to a problem we had. Without seeing all your design code I couldn't be certain, but one thing I've noticed in Edit+ is that even if you empty out a WYSIWYG field the HTML-tidy or some other cleanup process inserts empty <p> tags into it. So while you may think it's empty, it's actually got some HTML in there. From memory I think it will also try to wrap any existing content with <p>'s as well if it detects they are missing. So while the old WYSIWYG let you have truly empty and/or raw content without wrapping elements, the new one (in v5+) will not. This is a difference between the old WYSIWYG editor and Edit+, so the difference between v4.x and v5.x would very much explain it. You can test this yourself in EES, open code view, empty it completely, and hit save. Still looks empty but if you open up code view again <p> tags have been injected.
In your design or layout if you are then wrapping up the content of the WYSIWYG field with your own <p> tags (which is a very typical and intended use-case) then that would explain the double-tagging - one set of tags from your design, the other Edit+ is magically inserting. To test it out you could output the content of the field into a textarea, that will show whether there's an extra set of tags being included in the field by Edit+. Then your design wraps another pair around it. For example (*if* what I'm guessing is what's happening), you would have in your design or layout or somewhere something like this:
<p>%asset_metadata_FIELD%</p>
Pretty self-explanatory. And what you expect is this (and sometimes you do get this):
<!-- Old system (and untouched assets in new system: -->
<p> <!-- outer element generated by your design -->
xyz <!-- content you were expecting -->
</p>
But what you are getting is this:
<!-- New system (or on 'touched' assets): -->
<p> <!-- outer element generated by you design -->
<p> <!-- inner element you weren’t expecting but is now magically there -->
xyz <!-- content you were actually expecting -->
</p>
</p>
To make matters worse for you, what I've noticed is when you upgrade the content of the WYSIWYG field remains fine and as-expected with no extra tags in it, but as soon as you save or update the metadata on the asset the code cleanup runs and adds the extra tags in. But only that asset breaks. So you can very easily find yourself in a halfway point, where some assets have field values that are the old, correct values, but as soon as you action them and save, they 'mysteriously' start breaking, and all the time more and more assets are breaking. Your symptoms seem to fit.
I'm at home so can't test this, but if what I'm saying sounds plausible you could try using a replace keyword modifier with a regex when printing out the field to strip out the extra tags - however this may have other unwanted effects on the contents of the field. Failing that you may have to figure out whether you really want a WYSIWYG field at that point and either revert all the fields to a raw text field, or manually update all fields currently in existence so they all get the wrapping <p>'s and update your design to expect it, e.g. wrap in a <div> not a <p>. In both cases trigger batching is your friend (as absurd as that sounds).
