OFX import showing already matched transactions?

[Tracy]

Greetings,

(GnuCash 2.6.3, Window 7 64-bit)

I have downloaded transactions from my financial institution (in this 
case, transactions for a credit card) in QFX format, and I am working on 
importing these transactions into my register.

The large majority of these transactions already exist in the register 
(were manually added from the transaction receipts), with the 
transaction date specified along with the exact amount of the 
transaction. However, there are occasions where the transaction does not 
get manually entered (no receipt was provided, receipt was lost, etc), 
hence the download and matching of transactions from the financial 
institution (it is easier to remember a "missed" transaction from two 
days ago than one from three weeks ago during statement reconciliation).

When importing the QFX file, the "Generic import transaction matcher" 
window opens with the transactions listed, and some transactions already 
matched (reconcile) or partially matched (update & reconcile), and 
others listed as "Do not import" (which I assume means that the matcher 
was unable to identify the transaction with enough certainty to provide 
a match).

Now, because I am new to GnuCash, I am somewhat untrusting of the 
automated matching process. Therefore, I double-click each transaction 
to ensure that the match is correct (and I change the import type to 
"reconcile" after I verify each match, because I do not want the Payee 
that I have in my register to be changed - is there a setting to cause 
"update & reconcile" to respect the Payee names in my register? I 
haven't found one, so far...).

So, the problem. When I double-click on a transaction to verify the 
match, I am presented with a list of transactions which potentially 
match the transaction I am looking at. However, the presented list 
includes previously matched transactions. I believe this is incorrect 
behavior. If a register transaction has already been matched to an 
previously downloaded transaction, that transaction should not be 
offered for matching to a newly downloaded (ie. different) transaction. 
At the very least, it should be differentiated in some way, indicating 
to the user that it has been previously matched.

To give an example, let's say that I visit Subway regularly, and that 
(being a creature of habit) I order the same thing frequently, thus 
resulting in transactions with the same amounts, the same payee, but 
different dates, as in:

8/10/14   Subway      3.99
8/11/14   Subway      3.99
8/13/14   Subway      3.99
8/17/14   Subway      3.99

Now, if I download transactions on 8/15/14, and match them with the 
transactions in my register (thus matching the transactions from 8/10/14 
an 8/11/14), then download transactions again on 8/16/14, when I go to 
match transactions again, I should not see the transactions from 8/10/14 
and 8/11/14 offered as possible matches for the newly downloaded 
transactions (since they have already been previously matched). However, 
they do show up as potential choices, with no indication (at least, none 
that I have been able to identify) that they have been previously 
matched to a transaction....

Now, I could understand if they showed up in the list of transactions 
but were flagged in some way as having been previously matched 
(highlighted, different color, a column indicating they were previously 
matched, something). I could even understand them not being presented at 
all (because they were previously matched).

But from my point of view, as a user, there needs to be *some* way to 
differentiate "previously matched" transactions from transactions that 
are "unmatched", during the OFX/QFX import process - otherwise I'm going 
to end up matching two different transactions from my bank to a single 
transaction in my register (and then will end up potentially missing 
transactions, and having to go back through and search receipts during 
the statement reconciliation process to find out what went wrong).

Am I missing some obvious feature or setting that would enable this 
behavior, or is this truly "expected behavior"?

Tracy