I've been perusing some of the FlaggedRevs code recently (as it has evolved). It seems to be heading in a good direction. I'm not sure what ideas have been rumbling around in all your heads, but I thought I'd share the following thought with you in case it hasn't been brought up yet.
Performance is likely to be something of an issue, and will become more so as the database becomes populated with growing numbers of flagged revisions. Obviously the most common operation is to display the default version of an article. With FlaggedRevs this involves joining rows from the flaggedrevtags, flaggedrevs, and revision tables in a nontrivial database operation. The idea is to mostly avoid this with an additional table.
The table in its simplest form would just have two or three columns:
PageID (primary key)
RevID of the "latest stable revision" by namespace criteria
Valid flag for above RevID (or coded by NULL in revid, etc)
A default-revision access would go directly to this table and if a valid revid is found would then pick up the text of the page from the flaggedrevs table. If not found, the access would proceed as in the current approach. Possibly the access itself should put the resulting revid into the above shortcut table, but maybe this update would be done by a background task, or just by review-updates.
Once filled in, the default-revision access should be much better, even for only occasionally-accessed pages. Having this table requires that an update to the revid or valid flag be done when a page is given a new review setting, so that the new shortcut table will not persistently yield a wrong answer.
Now, all that seems good, but this table also should help with support of the number one wishlist item, per-page default-selection criteria. The shortcut table could record the criteria to be used for the page, perhaps in a text form convertable to the $wgFlaggedRevTags PHP variable which controls the selection.
With that in the table, a default-revision access would again use the revision found if it is set, otherwise select the revision using the page-specific criteria if they are present (otherwise the namespace default, of course). The table would also then be used in the other various flagged-revision queries, since it would be the residence of the per-page revision selection criteria.
I'd guess this idea has no particular implications for the early implementation now advancing rapidly, but it might be useful to ponder for work a bit down the road.
-RS