pg_upgrade may be mortally wounded

I re-enabled pg_upgrade this afternoon, thinking that it would be easier
to use than dump/initdb/reload for coping with the pg_statistic change
I'm about to commit. However, testing shows that it doesn't really
work. The "upgraded" database behaves very strangely --- vacuum tends
to fail, and I have seen duplicate listings for attributes of a relation
in psql's \d listing, broken links between a relation and its indices,
and other problems.

I think the problem is that pg_upgrade no longer works in the presence
of MVCC. In particular, forcibly moving the old database's pg_log into
the new is probably a bad idea when there is no similarity between the
sets of committed transaction numbers. I suspect the reason for the
strange behaviors I've seen is that after the pg_log copy, the system no
longer believes that all of the rows in the new database's system tables
have been committed.

Is it possible to make pg_upgrade work again, perhaps by requiring a
vacuum on the old and/or new databases just before the move happens?
Or must we consign pg_upgrade to the dustbin of history?

regards, tom lane