There has been a bug in SharePoint for as long as I can remember, when you embed a WebPart in a page layout elements file, duplication of WebParts can occur (if you switch two and from it). The quickest way around this was to manually delete the duplicated WebParts from the page after you have made the page layout switch.
Not great, especially when you consider that there may be multiple WebParts on one given page (or it may not be apparent that the duplications have occurred until after the publishing of the page). You could of course embed the WebParts in the page itself and bypass the page layout, but then if an author deletes the page, the WebParts that are intrinsically linked to that page will be lost (along with any settings that had been applied).
People have been battling with this problem for a long time. Developers would typically embed the WebPart(s) within the page layout directly (outside of the WebPart zone) bypassing the elements file, which in turn would remove the WebPart duplication problem but restrict access to the WebPart(s) on the page (for example, it would not allow people to change the WebPart settings or move the WebPart to a different zone on the page).
Another solution to this problem On Premise site collections was to use a well-established server side check to remove duplicates (comparing the WebParts against their siblings on the page). This requires server side code and access to the SharePoint publishing API, so this a no go for SharePoint Online (due to sandbox code restrictions).
The Proposed Solution
How It Works
This is the only public method within our helper plugin (DuplicateWebParts) which exposed for being called outside. If you take a look through the file, you will see it’s pretty heavily commented but if you need any clarification, give me a shout.
Duplicate WebParts Project – Download
Simply grab the zip file from my SkyDrive using the following link to take a look at this POC: SharePointCookies.WebPartManagement.DuplicateWebParts