>>Which I did already, years ago, in a field of c(200) type, which held statuses for other fields in the same record.

>I drop the binary approach, and change to a string method. Instead of examining the bits of the numerical flags variable, I am scanning a comma delimited string for the existence for the flags name. If exist, consider the flag as set, otherwise unset. Not only does this overcome the binary limitation, but adds to the readability in my code.

I am with Dragan that the method certainly will work - also that human input should be avoided.
But I also have some gut grumblings:
You were looking for a method to search many flags - search time will grow worse by a lot if flag count is increased a lot. Using Lutz' hint of empty object might be slower for low # of flags (guessing, not benchmarked), but will have less time added for very high # of flags.

This might be in part a false dichotomy, equating search mechanism to a persistance format: from a csv string any empty flag object can be built with ease via alines() and searched with less varying search times.

I often use csv filter help fields built in stage tables of SQL - but those are very short, usually less than 6 items.
Probably not really important for most use cases, but my loads sometimes ran for days on many machines, handling big iron data chunked down to vfp - sized table bites, so I worry always about perf on changing data loads.

my 0.02€
thomas