One could also think of giving the new field a wider range than 0 and 1, for future purposes. For example, one user suggested flagging revisions that have been restored with the old deletion schema. One could also think of the state "belonging to a deleted page". When we switch entirely to RevisionDelete, we still want to show revisions in the history that have been RevDeleted, but we don't want to show revisions of a previous attempt at writing the article.
E.g.:

1. Vandal creates page A
2. Page A gets deleted with RevisionDelete, revision X is marked as deleted
3. GoodUser creates page A
4. Oversight action on one specific revision Y in A
5. How do we make Y show up in the history (because it belongs to the article), but not X (which has nothing to do with the current article)?

One simple way of doing this would be to only display RevDeleted revisions in the history, if there's an earlier revision that is *not* deleted. Another way would be to store this information directly in the database.

Perhaps use a bitfield (tinyint), just like in rev_deleted? One could name it rev_attrib.

What about simply adding a tag (MediaWiki-Change-tagging)? This doesn’t need new infrastructure, and I think it would qualify the requirements listed in the task description.