Kind of a fiddly naming issue, but there are a lot of places where flag-testing helpers are defined, which usually have 4 variants like this:
#define Set_Details_Flag(p,name) \
Set_Flavor_Flag(DETAILS, ensure(Details*, (p)), name)
#define Get_Details_Flag(p,name) \
Get_Flavor_Flag(DETAILS, ensure(Details*, (p)), name)
#define Clear_Details_Flag(p,name) \
Clear_Flavor_Flag(DETAILS, ensure(Details*, (p)), name)
#define Not_Details_Flag(p,name) \
Not_Flavor_Flag(DETAILS, ensure(Details*, (p)), name)
The savings add up for having things like the NOT form, it unclutters things pretty well:
Not_Details_Flag(details, CAN_BE_DISPATCHED_AS_INTRINSIC)
// vs
not Get_Details_Flag(details, CAN_BE_DISPATCHED_AS_INTRINSIC)
I hadn't really questioned these. But lately I've been wondering... would HAS be better than GET?
if (Has_Details_Flag(...)) ...
if (Get_Details_Flag(...)) ...
It's a subtle semantics thing. You could argue that even if a flag is not set, the structure still has the flag.
But is "if Get(...)" like asking if the get operation itself succeeded? 
Of course, in the interpreter we have taken for granted that if get $var isn't asking if you successfully got the variable, but whether the variable's contents are null or not. And has obj field is really asking about the presence or absence of the field.
When I first thought of it, I was thinking that HAS was better. But after writing this I'm kind of thinking GET may be the more consistent choice after all.
To be painfully precise, we'd call it: Is_Details_Flag_Set(...)... but I certainly prefer Get_Details_Flag(...) to that.