First SM poser support and poser errors reported with V4 stuff as example is a general problem cause SM is not accepting that Poser is a program with errors independend which stuff you use. So in their mind it's only a error if proven with their own stuff.
This is sort like MS Word errors are only errors if happening with letters written by MS office clerks ... a silly and total contraproductive behavior ... but to avoid early trouble with the support try to prove errors with SM stuff even if you never use them normally ... :cursing:

Now to that ERC problem ... YES, it is a new and very tricky bug with SR3.
To be honest I didn't find this but I had a JCM creation question with morphing clothes and D3D did inform me exactly about this (your) problem.

It's not a general ERC problem but it's a problem with superconforming or crosstalk driven morphs (JCM's all, FBM's mostly.

Normally you have two methods to implement this in the addDelta section.
Either you use :X behind the actor name and if X is not the otherwise used :X number for the actors in that figure than it's understood as crosstalked/superconforming.
For example all BODY, hip, neck, etc. is set to :2 but the number behind BODY: in delta section is a 1.

The other, may be more common, version of superconforming is to let the :X in the delta section completely out. So instead of BODY:1 there is only BODY written.

And exactly this second version is demolished with SR3. So in this case the crosstalk is broken and will not work like before. This is the point cause most of DAZ stuff is touched (they work this way) while other stuff (with different :X numbers) will work as with former SR versions.

And if this is not complicated enough this buggy behavior is only happening if the stuff is loaded via a python method.
This means if you use a external library tool like XL or P3dO which are mostly work via python you are one of the happy winners of the newest bug. If you use that standard library with the crappy flash stuff then the bug will not happen this way.
There are indicators that Poser is running in trouble while renumbering the :X to actual numbers in the loading phase but only in case the :X is left out.

I'm not sure but I guess with this new non (well) functioning "morph with conforming" method in SR3 they have demolish a lot of the once before working stuff cause this new function has to deal with all that stuff.

As far as I see they are specialists in finding only half of their functions if trying something new.  For example with SR3 they should have fixed in the end all that problem stuff with european decimal separators. But no, they only repaired it in the joint control window. But if you try to use a comma as decimal point in the crease angle box you will find that it's not working. I can't understand that. Normally it's the advantage of modular coding to have the checking stuff only once at a input window and use this window at every place in the program where needed. But in Poser each single window or box seems to have it's own coding and furtheron there seems not to exist any plan about which function is used somewhere in the program. So it's not sufficient to tell them that they have a problem with the comma as  separator at numerical fields, no, no, you have to list all this fields as complete as possible that they find them all while correcting their bugs ..... :cursing:

And so I think while implementing that new "morph conforming" stuff they have not found all positions where this will influence the workflow in poser ... et voila, you are in problems with the classical crosstalk ...

Ok, otherwise this is the result if someone is declaring a bug (what crosstalk original was/is) to be a feature (under the new name superconforming) ... :laugh: