Last architectural problem: override a link's status in the sitemap (inclusion/exclusion)

We have one major remaining architechtural problem in the 6.x-2.x rewrite: 'overriding' the default status (inclusion/exclusion) from the sitemap.

The 6.x-1.x version currently lump both status and priority values into one column: priority. If priority = -2, the link is included and has default priority. If priority = -1, then the link is excluded from the sitemap. If the priority is a value from 0.0 to 1.0, the link is included and has the assigned priority value.

I wanted to keep the status and priority values as separate fields in the 6.x-2.x rewrite because then it is easy to change the default status or priority for a content type, and have those changes be immediately applied to the existing data in the xmlsitemap table with one simple UPDATE SQL. In the 6.x-2.x we currently have an boolean access column, which stores whether a link is visible or not (like if a node is private or published), a boolean status field if the link is included or excluded by default (the content type setting), a priority column which is the default priority for the item, and finally a priority_override column which if it is not NULL, overrides the priority field (COALESCE(priority_override, priority) as priority). See http://project.davereid.net/api/function/xmlsitemap_schema/xmlsitemap

But now I need to figure out how to store in the database (and expose in the interface) how to override the status value to include or exclude a specific link. I have come up with three solutions:

1. Create a status_override column, similar to the priority_override column.
   If the value of status_override is NULL, then the value of status is used. Otherwise, the value of status_override is used.
   Pros: Consistency with the way the priority overriding works. We can easily update the default status values for content types, vocabularies, etc since status is still its own column. Easiest to understand what is going on in the database.
   Cons: In order to select all the links that are visible in the sitemap, we need to have COALESCE(status_override, status) = 1 which will not be as efficient for sites that will have large amounts of data in the table. Code is a little more complex in the interface since we can't easily give a select option element a NULL result value.
2. Create constants for all possible status values and just use the status field.
   For example: XMLSITEMAP_STATUS_EXCLUDED = 0, XMLSITEMAP_STATUS_INCLUDED = 1, XMLSITEMAP_STATUS_EXCLUDED_OVERRIDE = 2, XMLSITEMAP_STATUS_INCLUDED_OVERRIDE = 3.
   Pros: Only one database column and easy to index.. To select included links, we only need to have WHERE status = XMLSITEMAP_STATUS_INCLUDED OR status = XMLSITEMAP_STATUS_INCLUDED_OVERRIDE.
   Cons: Not as easy to tell what is going on in the database. I don't link to use constants.
3. Use a negative status value to represent a status override and just use the status field.
   For example, link excluded by default = 1, link included by default = 2, link overridden to be excluded = -1, link overridden to be included = -2.
   Pros: Only one database column and easy to index. Again to select the included links we just need to have WHERE status = 2 OR status = -2 or possibly ABS(status) = 2 but the latter is probably not as efficient.
   Cons: We can't use boolean 0/1 logic for status, which is not as easy to understand what is going on. Probably still need to use constants.

I'd like your input on what makes the most sense from an architectural standpoint since there's not really anything in Drupal core as an example that I can follow. If anyone has any more suggestions, let me hear 'em please!