I rather avoid things like
ViewStatus viewStatus;
since it introduces a new class without giving you anything in return when compared to
boolean isViewed;
But that's a matter of personal taste.
By setting the reference to null you can have a third value, which is not really good, since you can get an unexpected NPEsomewhere; null is just no "first class value".
EnumSet pretty much exists specifically for this purpose, but... it seems like just two much overhead. Especially when reading the values in the part of the code that builds the HQL.
The overhead of an EnumSet is reasonable, it caches the class and an array of all values, and uses a long for storing the data (as long as the enum is small enought). Its equals method is quite fast, but obviously slower than reference comparison. You mentioned using HQL, so most probably the runtime will be dominated by the database access, so IMHO you're needless and premature optimization.
The mutability of the EnumSet may be a problem sometimes, but there's ImmutableEnumSet in guava.
I'll go for an EnumSet because I want to introduce methods on that enum that wouldn't make sense to be called on ALL. For example ViewStatus.isViewed().
I don't think you stated all your alternatives right. You can have both
enum ViewStatus {VIEWED, UNVIEWED}
and
enum ViewStatuses {VIEWED, UNVIEWED, ALL}
where the second is an replacement for the EnumSet. That said, I agree with your decision.
The linked questions identify a load of issues in current macro languages. If you're going to design a new language, you should address those those issues.
For instance, take the define TWO 1+1; TWO*TWO=3 example. You can make your language robust by not including a rule for 1+1*1+1; instead require arithmetic expressions to be explicitly parenthesized. That means 1+1*1+1 is a syntax error, and should be written as (1+1)*(1+1).
Best Answer
Possible Uses
Fast Prototyping
You could do this with Groovy or others, so that's not a very strong point, but as CRaSH gives you code-level access to the JVM and the processes it runs, it may come in handy to just keep a JVM running and experiment with small code snippets (for instance, using it as a REPL to implement solutions to StackOverflow questions).
The JCR extension would seem potentially useful to supplement this, by giving you shell access to remote repositories, and contains a notion of workspace to separate projects.
Interacting with a Running Process
I could see this being an interesting use case. I don't know of many good process inspection command-line tools for JVM processes, apart from the JDK-packaged ones. CRaSH might help in interacting with them in novel ways.
For instance, you can use the Attach Mode to attach to a running JVM, and then use the
threadcommand tols,dumporinterruptthreads.You could also write some additional control commands for non-programmers to use CRaSH to perform routine maintenance and monitoring.
Content Repository Management
The JCR extension seems to be very interesting as well, as it would give a Java-scriptable access to remote development environments. It could also simply allow content-editors to access and edit remote content, when used in the context of CMS-type apps built on top of a JCR-capable content repository.
What Others Say About CRaSH
An introductory blog post by the CRaSH author, about its use at eXoPlatform. And the fact that it is officially supported by eXoPlatform is an indicator that's it potentially good stuff :)
Not much to read, but of interest: French technologist Didier Girard re-posted it.
Summary
Basically, I see it as a power-user or administrator interface to JVM processes, built on top of Groovy and networking protocols. So it combines the power of scripting with a nice facade and some built-in connectors.
Note on Flexibility
I agree with SK-logic: most of this can be done with most JVM-languages, and they provide more and flexibility. But CRaSH might provide a shorter path to achieving such goals.
The same applies to the JCR extension capabilities: you can achieve this by glueing together a few age-old and time-tested tools. But this might be a shorter and simpler path (like commands for the heroku platform, or PaaS services, for instance).