>First, a deleted record doesn't mean you could use its PK value, unless packed. So it would be meaningless to use a filtered key or a tag on deleted() just for PK check (a dummy tag on deleted() have always purpose, but not this one).

If you think about surrogate keys (with no meaning to the user). But when we regard a non surrogate key, we need filtered , candidate tag. Example - an invoice: a consecutive number of the invoice.

>With a generator routine you could be 100% sure that a key is unique w/o checking it. Of course you would need some checking on startup.

We are entering the area of Murphy laws.
But I must agree with your notice about nonsense surrogate key checking before TABLEUPDATE(). Such checking has to be performed just before saving the record and after locking the table.

LOCK...
DO WHILE .T.
   lcKey = generate(...)
   IF !SEEK(lcKey)      && You only seek your buffer+physically written !
      EXIT
   ENDIF
ENDDO
REPLACE Tag_PK WITH lcKey
TABLEUPDATE
UNLOCK

After articles in FoxPro Advisor presenting speed advantages of INTEGER keys, I decided to use as surrogate primary keys only such keys. That's why I don't suggest using SYS(2015).

Thanks for your notices.