My problem is understood - and has fortunately nothing to do with a memory corruption. Its real cause is request caching by Products.PluginIndexes.unindex.UnIndex. It uses for this caching a request key of the form '_catalogcache_{0}_{1}'.format(catalog.getId(), id(catalog)). Our migration script it started with bin/client1 run and this implicitly arranges for the creation of a request object. The script then iterates over the portals (more than 1000) and migrates each portal in turn. Apparently, for some of those portals p, id(p.portal_catalog._catalog) is identical and the index returns buggy cached results from a formerly migrated catalog - and naturally not understood by the current one.
Workaround: clear the request before each portal migration.
I never understood why UnIndex must use request caching: it should be quite rare that the same request issues the same query against the same index more than once. This "feature" is dangerous, especially for scripts for which there is no explicit request. This is aggravated by UnIndex forgetting to invalidate the cache on modifications: thus the second "search" in a "search, modify, search" sequence can give outdated results.