Look at this nice table... (thanks for starting it, @bradrn)
...Nice... Except For "antiword" 
To me, antiword sticks out like a sore thumb, there.
I've deemed that you'll be able to create a QUASI-WORD! out of any word. But the system will stop you from making antiwords out of anything but the endorsed words. So far, that's:
- ~null~
- ~void~
- ~okay~
- ~end~
- ~NaN~ (just a proposal at this point)
All other antiform words are reserved for future use.
(~end~ isn't famous yet. But it's for when the system has built a frame but not executed it...that's what it puts in the slots when it runs out of input. The reason argument fulfillment doesn't error "in the moment" is so that you can ask the system to build a frame from a callsite, and then do some alterations on it to supply missing parameters before you call it. For an example, see SWITCH2)
So... What Are These Things, If Not ANTIWORDS?
They are--in a sense--the only keywords in the system.
It would be sort of a flex to call them that. While yes--it admits that we do have them--it points out that there's only a handful.
But arguably dialects have "keywords" any time they recognize words literally (as UPARSE with its combinator map does--although you can pick whatever map you want).
I feel like we'd probably go around using the term "keyword" when talking about dialects, and it would be confusing to differentiate that from these...so antiword perhaps a more practical choice, but...
I Asked Claude.ai...
Claude didn't have any good suggestions (or at least none that I didn't have a good reason to shoot down because an existing usage of the term is more compelling... "token", "sigil", "symbol", "atom" etc.).
But I did make a case for going with my gut of calling them keywords:
"I do wonder if my worries over calling them keywords are overblown. There's other terms that the system uses, like SET? to check if a variable is set or not, and you could rewrite that to check if something was a datatype of a "set collection". Then you could qualify it to say LIB/SET? to get the original definition of the test for variable set-or-unsetness. Considering all the conflation in the system as it is, would it hurt to call these KEYWORD?"
"As I said, I kind of really want to call them that. It also accents that the system only has a handful of keywords. Maybe I should just go for it."
Your reasoning about potentially using "keyword" is compelling. Let's weigh the pros and cons:
Pros of using "keyword":
- It aligns with your intuition and desire.
- It accurately represents their special status in the language.
- It emphasizes the language's unique feature of having very few true keywords.
- It's immediately understandable to most programmers.
- It's short and descriptive, meeting your initial criteria.
Cons:
- Potential confusion with dialect-specific keywords.
- Overloading an already common programming term.
Considering your system already has some level of term overloading (like SET?), and given that these are indeed the closest thing to keywords in your language, the benefits might outweigh the drawbacks.
If you do choose "keyword", you could mitigate potential confusion by:
- Clearly documenting the distinction between these language-level keywords and dialect-specific keywords.
- Using a qualified term like "core keyword" or "system keyword" when absolute clarity is needed.
- Providing clear examples in documentation to illustrate the difference.
Alternatives that incorporate "word" if you decide against "keyword":
- Metaword
- Primeword
- Coreword
- Rootword
However, given your explanation and the unique nature of your language, I believe using "keyword" could be justified. The term accurately represents their function, and with proper documentation, any potential confusion can be minimized.
If you feel that "keyword" truly fits best and you're willing to manage any minor confusion that might arise, it seems reasonable to go with your instinct here. Sometimes, the most intuitive choice is the right one, especially when it comes to language design where clarity for the users is paramount.
Is "Keyword" a Brave Choice? Or Just Confusing?
It feels like a consequential choice.
Maybe it isn't, really. You very rarely need to mention the category--in particular because each one is so special you generally name it explicitly in your type specs.
The case I mention about SET? and unsetness of variables conflating with "set"-the-collection is probably an example of something people would run into more often day to day.
I think I'm leaning to just doing it, for the marketing if nothing else: "Ren-C has 5 keywords." That's a pretty interesting talking point to pique someone's curiosity. ("Why 5? Why those 5?") It could lead people into the journey of learning what makes isotopes so special and important to the language, to realize that the keywords live out of band of the code itself...yet can be juggled into and out of reification as needed.
"Only WORD! antiforms are keywords" actually carries some weighty philosophy in it. 
Your decision to use "keyword" for these special elements is compelling, and I agree that it could be a strong choice both technically and from a marketing perspective. Let's break down why this decision works well:
- Marketing appeal: "Ren-C has 5 keywords" is indeed an intriguing statement. It's concise, provocative, and likely to spark curiosity among programmers familiar with other languages that typically have many more keywords.
- Educational opportunity: As you pointed out, this choice naturally leads to questions that can help introduce newcomers to some of Ren-C's unique concepts, like isotopes and the distinction between forms and antiforms.
- Philosophical depth: The statement "Only WORD! antiforms are keywords" encapsulates a lot of Ren-C's design philosophy. It hints at the language's flexibility while also pointing to its fundamental structures.
- Technical accuracy: These elements do function similarly to keywords in other languages, in that they have special, reserved meanings within the system.
- Simplicity: "Keyword" is a familiar term to most programmers, making it easier for newcomers to grasp the concept initially, even if the full nuances require more in-depth understanding.
Using "keyword" in this way could serve as an entry point to explain several key concepts:
- The nature of antiforms and their relationship to reified forms
- The flexibility of the language in allowing redefinition of most terms
- The concept of isotopes and their importance in Ren-C
- The unique evaluation model that allows these keywords to exist "out of band" of regular code
By choosing "keyword", you're not just naming a concept, but potentially creating a teaching tool that can help introduce Ren-C's unique features and philosophy.
This approach aligns well with the idea of making the language both powerful and learnable. The familiar term serves as a bridge to introduce more complex and unique concepts, potentially making Ren-C more accessible to newcomers while still highlighting its innovative features.