Comment 3 for bug 704051

Raphael, thanks for investigating in details this issue and providing a reproducible testcase.
It makes it easier to fix the issue! :-)

Basically, inheriting from ir.model.data causes the osv instance for 'ir.model.data' in the pool to be replaced, discarding the current list of known "XML ids", stored in ir.model.data.loads.
Recently we changed the module data cleanup to be done globally at the end of the module install/update process, to avoid other issues, and thus it became important for this 'loads' cache of known XML ids to survive replacement of the osv instance in the pool.

The fix places a reference to this cache in an attribute of the pool object, to have it survive properly. It was pushed in
server trunk with revision revision-id: <email address hidden>

Note that the amount of module data being discarded by this bug depends on the number of modules that were processed before the base_external_referentials modules, which should be quite low, as it only depends on base, and is processed before any module with deeper dependencies. Also note that after updating to the latest revision and starting another --update=all, any missing module data will be properly restored, as long as discarded data only included actual module data, and no data that 'pretended' to be part of a module.

Thanks for the bug report!