Spec merge has changed what it does from release to release. But the basic idea is that it assists in combining a customers custom modifications with the JDE version.
As you know, both JDE and customers modify applications. The challenge then is: how does one automate the combination of the two sources of modification so that the end result functions as expected. As you can imagine this is not the easiest task to implement given that applications have TAM components, ER, and business function components.
During an upgrade, spec merge treats the JDE object as the "Source" object. All the customer's custom mods are combined into the JDE object. For instance, if a customer added ER, spec merge does the following:
1. Uses the JDE ER and you use Visual ER compare to manually re-add your ER changes back in.
2. Does its best to combine the form/report controls.
3. Does nothing with business functions - i.e. uses JDE vanilla version of the business function. It is up to you to manually apply any business function change.
For an ESU the same process except the customer copy is the "source" object.
Service Packs in general do not invoke spec merge at all. Service Packs modify the system directory not the specs. You may, however, have to re-link business functions depending on the service pack. But this does not involve spec merge.
In the example you stated, when one upgrades P4210 from B7333 to B7334:
You have to go to the merge selection form and enable the merge for P4210. If you do not do this on an upgrade, spec merge simply copies the vanilla JDE object over. If you do specify this option then spec merge will do steps 1-3 listed above.
Cheers,
Chris