I did some more digging : the problem is far more deeper in the sense that multiple XMP packets in a pdf turns out to be a normal behavior (called "incremental save"), but acrobat itself does very strange things with metadata, depending on what is updated, from where, and this leads to weird discrepancies. Moreover, acrobat (acrobat pro X) is sometimes "lying" about the exact actual content of metadata in the pdf. So, I begin to realise how painfull it could be to write the pdfpropertyextension....
At the moment, what I understand is that there are two ways to store metadata in a pdf : in an XMP packet, and in an "information dictionary" (ie. one line near the end of the pdf source).
Each time a pdf is saved, acrobat does indeed an incrematal save : the existing XMP packet is not modified, but a new one is created. So the pdf does keep the history of the metadata modifications. But : the information dictionary is not incrementaly saved : there is always -as far as I see- one and only one infodictionary in the pdf.
An important behavior of acrobat (but you have to dig hundreds of pages of technical doc to eventually find it) is that if a pdf is saved by "save as", then the metadata history is cleaned, so it remains only one XMP Packet (the last) and the info dictionary in the pdf.
First, there is a problem when updating metadata with the properties poupup window in acrobat (ie. without running javascript to access the Doc.info object, nor using E4X to set an XMP packet). If you take a minimal pdf (e.g. create a pdf from a blank.txt) and you sanitize it : there is no XMP packet and no infodictionary in the pdf source. Then you add "ptitre" as title with the properties popup: when the pdf is saved, an XMP Packet is created with "ptitre" in the creator element of the dublin core, and an infodictionary is created, with a title "ptitre". And PdfPropertyexension displays "ptitre", as expected.
Then, if the title "ptitre" is removed with the popup, and the pdf saved, "ptitre" is removed from the infodictionary, and a new XMP packet is created with an empty creator element. And PdfPropertyexension does not display any more title.
Then, if we aplly the same procedure with the Author metadata, it produces a similar -appropriate- behavior. the "pauteur" created is displayed by pdfpropertyextension, then blanked when removed with the properties popup.
But : if we now add "pkey" as keyword with the properties popup and save the pdf : pdfpropertyextension displays "pkey". In the pdf source, "pkey" is added at three places : in a newly created subject element of the dublin core, in a newly created pdf keywords element, and in the infodictionary.
Now, if we remove "pkey" with the properties popup, pdfpropertyexentsion still displays "pkey". Is this a pdfpropertyextension bug? It does not seem. This is acrobat weird behavior : when "pkey" is removed with the popup, and the pdf saved, in the pdf source the subject element is removed from the dublin core and the pdf keywords element is removed, but : "pkey" is actualy not removed from the infodictionary.
So, it seems that pdfpropertyextension first reads the infodictionary (knowing that the modification dates of the xmp packet and of the infodictionary are exactly identical).
The question is : could it be possible to have an option in pdfpropertyextension to take first the last xmp packet into account, instead of the infodictionary content?
Moreover: We sanitize again the pdf. The xmp packet and infodictionary are removed from the source. then we use the console to run this.info.Author="cauteur"; The properties popup then displays "cauteur" as author. And more : the advanced panel of the popup displays "cauteur" in a creator element of the dublin core. If we save the pdf : pdfpropertyextension does not display "cauteur". Is this a pdfpropertyextension bug? No. If we look at the pdf source : there is no xmp packet, and no infodictionary. In this case, acrobat does not update the pdf source with the modifications it itself deceptively displays to the user interface when the pdf is saved. In that case : it seems obvious that there is nothing that can be done with pdfpropertyextension to circumvent the problem.
Then, we sanitize again. then add "ptitre" as title and "pauteur" as author with the popup. we save the pdf. pdfpropertyxetension displays "ptitre" and "pauteur". We save the pdf with "save as". In the pdf source, the creator element contains "pauteur" and the title element contains "ptitre", but the infodictionary is removed. Pdfpropertyextensions still displays "pauteur" and "ptitre" : that is, it is taking the xmp into account (since the info dictionary does not exist anymore). Then we run this.info.Keywords="ckey"; in the console and save the pdf. Pdfpropertyextension displays "ckey". In the pdf source : the last xmp packet contains a pdf keywords with "ckey", but no dublin core subject elemnt, and thre is no infodictionary. Again, pdf property extension reads the xmp packet since there is no infodictionary.
Then we open the properties popup, which displays "ckey" and substitute this value with "pkey", then save. Pdfpropertyextension displays pkey, pauteur, and ptitre. In the pdf source a subject element with "pkey" is added to the dublin core, and the pdf keywords element now contains "pkey", and, an info dictionary is created, with pauteur, ptitre, and pkey. The, we run this.info.Keywords="ckey"; with the console, and save. pdfpropertyextension displays "ckey" and does not take into account the "pkey" value wich was set with the properties popup. and in the pdf source, the info dictionary and the pdf keywords element contains "ckey", but : the subject element in the dublin core contains "pkey". The popup displays ckey;pkey in the keywords field.
And again acrobat is lying : the advanced panel diplays a dublin core subject element with :[1]ckey, and [2]pkey, and a pdf keywords set to ckey;pkey. Actually, what the pdf source contains is a subject element with only "pkey" and a pdf element with only "ckey". the infodictionary contains "ckey". Pdfpropertyextension only displays "ckey".
Here again, it would be cool that Pdfpropertyextension allows to first take the laxt xmp packet into account, rather than the infodictionary.
There are actually some more problems, especially when dealing with adding multiple keywords with javascript (if what is needed is to get real separated keywords, and not a string that is only one keyword within double quotes with pseudo keywords separated by commas or semicolons).
I'm digging this issue too...