Here is a modified version of the alternate proposal which fixes up some minor issues and is, hopefully, easier to follow... It is a long version of what I see as the classification and processing for Compare/alt-Compare -- It is sumarized in a reply to one of John's postings in this thread...

It is an "algorithm" which means you have to walk out the individual steps since each step is dependent on the previous step(s)... The algorithn is:

First, don't even think (yet!) about what the user has set for Identical/Unique/Newer/Older/Error (or whatever word we use...). Using just the other settings (the ones on the bottom line which are all "toggles"), proceed as follows:

The bottom prompt line reads as follows (same size as current one!!):

  ignore sFn(y) and Case(n), checK(Body) {:}And(DaTe)     OR
  ignore sFn(y) and Case(y), checK(siZe) {&}viA(Ver.)

The uppercase letters are highlighted as "toggles" as are the "&" and ":" (":" could be changed to "#", "%", or any other character that makes mneumonic sense to people). The special character toggles between "{:}And" and "{&}viA" -- it's not clear whether "&" (allow 'unshifted' as "7" too) should toggle it or just set it to "{:}And". The values and meanings are as follows:

Case: whether the case of the LFNs matters or not
sFn: whether the SFNs matter or not...

Generally, a mis-match of Case or sFn will cause the pair of files to be classified as an "Error", but there are times when one might want to treat them as Unique. I suggest that we allow shift-C and shift-F to set (toggle) the Case/sFn choice to "U" which indicates that a mis-match there causes the pair to get classified as "Unique" rather than as an "Error" (sFn has precedence over Case -- that's why they are ordered as above).

checK: values are "name", "siZe", "Body" (maybe others someday) --
  "name" is always TRUE (the names match...)
  "siZe" checks that the files are the same size
  "Body" does a binary file compare (new word for "Binary")
  [TBD] Attributes ("RASH" with no highlights?), possibly allowing a "mask" to specify which ones to check, e.g., allow "R_SH". etc...
  [TBD] I could see allowing sfn, version, and case here too...
  [TBD] "info" covering all of case, sfn, version (if available), and attributes
  [TBD] "all" covering "info" AND "body"
  [TBD] others (suggestions anyone??).
    "K" cycles through the choices, while
    "B" toggles name/siZe to Body and Body to siZe
    "Z" toggles between "name" and "siZe" (Body->siZe)
    shift-B/Z toggle to "name" rather than "siZe"

The values for the ()-ed item at the end specify what is being used as a "date thingy", and include:
  "Time" -- Full date/time
  "DaTe" -- Just the date (time part ignored)
  "Ver." -- Version info (a lot like a date...--See below)
  "creD" -- TBD Creation date(? /time ?) [any abbreviation OK]
  "accD" -- TBD Access date(? /time ?)
  others -- TBD, but see below for version variations...
    An "A" cycles through (all) the choices
    A "D" cycles through the three date variants
    A "T" toggles between "Time" and "Date"
    A "V" toggles between "Ver." and "Time" (or "Date"??).

When checking "version", there are four cases:

--- Both have versions, they are comparible.
--- Neither has version info.
--- One has it and one doesn't
--- Both have it but the values can't be compared (due to format...-- Always an "Error")

The handling of the middle two cases needs discussion... One way is to say that a file with version info is more recent than one without and to fall back on date/time if neither file has version info (called "version-then-date"). We could, alternatively, say that one or both should be treated as an "Error" (or is to be considered "Unique" to avoid dropping too many things into "Error"). Unfortunately, there is no really good place to indicate (all of) this in the prompt -- shift-V could be used to toggle/cycle it, but where is it on the screen? My suggestion is:
-- "Ver." -- "Error" if one or both don't have version info.
-- "V:dt" -- The version-then-date form...
-- "V&dt" -- Check/order-by version, and if equal, use date (use version-then-date for missing info)
-- "#Ver" -- Missing version info goes to "Unique"

The "date thingy" is used in two ways -- first, it controls classification into Newer/Older/Error, and second, it may be included as part of the "identical" checking), according to:

The "special character" toggles between:
  "{:}And" -- Check date thingies of the two files for equal.
  "{&}viA" -- Just use the thingy for classification).

The logic of the checks(case/sfn/etc.), is essentially AND, i.e., a pair must satisfy all of the checks to be "identical". OR logic can be obtained through multiple passes (see the shortcut below!!).

The files are classified according to the above into one of the following classes:

Unique -- No matching file ([TBD] may be SFN...)
Identical -- Satisfies all of the specified identity checks.
Newer -- Fails some check, "date thingy" for source more recent (assumes comparable).
Older -- Same, but target more recent.
Error -- Have a pair of equal (ignoring case) LFN's, but something odd is afoot -- Could be:
  -- Not identical, same date
  -- "date thingies" not comparible (version format different or no version in one...).
  -- Failed Case or sFn.
  -- Access error for a file (e.g., if it hits WIN386.SWP).

I think all of the things under "Error" really are that in some sense, although the "U" option for Case/sFn is desirable... I could also see adding one more category called something like "Exception", "Queer", "SameD", or "#date", or something similar, which is where date "errors" would go (equal date for different file content or non-comparable "date"[version]), but I'm not sure that it is needed or whether we could squeeze it in....

It is usually obvious which class a file or pair falls into, but the exact algorithm is important in a few places... The detail is needed to make sure that we know EXACTLY what happens:

FOR each file (or pair), classify it as follows:

1) See if there is a matching target file. For now this is JUST: "same LFN (with case ignored) on the same relative path" (the "relative path" only matters for alt-Compare).

2) If there is no match (see below regarding Case/SFN mismatches), the file is CLASSIFIED as "unique".

3) The Case and SFN settings are checked now, and if the file pair fails these checks it is classified (as a "pair") as an "Error" (or, as "Unique" if "U" is allowed in place of Y/N).

[Aside] Shortcut: At this point, especially if checking binary or version, it is probably worthwhile to see if the source (and target) file is already appropriately marked/tagged -- If so, there is no need to do any further processing. This optimization is especially important for doing OR logic via multiple Compare passes...).

4) If there is a match, we check the file pair for "identity", as follows:

  a) "Content" check: This is controlled by the setting/toggle following the word "checK". The options are (we may add others in the future...):

Name [only -- an always true (NOP) since those match...]
Size
Body [full content check using a "Binary" compare]

  b) "Date" check: If the "special character" toggle (for "And"/"viA") is set to "viA", there is no date check. If it is set to "And", check the selected "date thingies" for the two files for equality.

  If the pair of files satisfies the specified checks, they (as a pair) are classified as "identical. Otherwise:

5) The "date thingies" are compared for greater-than/less-than/equal (see below for what to do if they can't be "compared") and, if:

  a) If the source file's "date" is before the target file's, the PAIR is classified as "Older"

  b) If the source's is after the target's, classify the pair as "Newer".

  c) If the "date thingies" can't be compared (i.e., different version info formats), class as an "Error" or possibly under "#date" (if implemented...)?

  d) Otherwise, the pair is classified under "Error".

Once the classification is determined, the middle line of the prompt comes into play. The setting for the appropriate item is examined, and, if it specifies an "action", take that action (against the file pair)... Currently the only two actions are "tag" and "no action", but I would like to see the list expanded. Note that the action is applied to the PAIR and may affect both files...

There are 3 levels of enhancement here:

First, extend the choices to Tag/Untag/no-action. The hotkey (I/U/N/O/E, maybe X or Q) still toggles between Y and N (or, probably better, "Tg" and "--"), but a shift-I/U/N/O/E toggles through a cycle which also contains "Un" (or "U"). If the action for a category is set to "Un", files falling into that category are Untagged.

Second, it would be nice to be able to manipulate the target file tagging as well as the source file tags. To do this, one could extend the shift-I/U/N/O/E cycle, but I suggest that instead it would result in a sub-prompt (sort of like a "point") in which a mask (like the ctrl-Attributes mask) is filled in. The syntax is:
  <+|-|!>
which specifies tag/untag/invert for file/target -- the "X" is a special purpose variant of Target for "Unique" which indicates that any target files which are not matched against a source file should have the appropriate action taken against it's tag...

Third, if/when the proposed tagging extentions are implemented, shift-I/U/N/O/E would allow one to enter a standard attributes/tag mask -- this is really just an extension of the second form to handle the extended tags although it would also (at least theoretically) allow things like "-A" which would change that attribute of the source file...