Hi Tom,
I see you smile when declaring this a feature...
I think the handling of table validation with SET TABLEVALIDATE has a flaw in logic: It assumes that it can always lock the header of the table, and if it can not it assumes that something is wrong and generates an error.

Consider this, real life, scenario:
We have table that must updated from one computer only (a data logger app.). The table is valid, so we have no problem opening it and issuing a FLOCK() on the designated computer.
We need to open the table read-only in many other applications – but, if we want the so called TABLEVALIDATE feature enabled, we end up in an “Attempting to lock…” and an error “File in use by another user”. The error affects the entire MIS Applications system, now the only option we have is to disable the table validation.

I believe that the correct behavior is that if a table header cannot be locked TABLEVALIDATE should not generate an error, in other words, should assume nothing and do nothing.