I was looking at this from the emscripten config file:
; Right now, either #web or #node (someday #wasm-edge ?)
;
javascript-environment: #web
And I thought to myself: well that's kind of ugly. The comment is having to list things that would be more obviously shown by just demonstrating the options:
javascript-environment: circled [(#web) #node]
It could default to NULL if you circled nothing, but you could use MUST to suggest people needed to select something:
>> number: must circled [#one #two #three]
** Error: MUST requires argument not to be NULL
It's Almost Too Easy
When it's this easy, who wouldn't whip such things up?
circled: lambda [block [block!] <local> result] [
parse block [
result: try thru subparse group! [
<any> <end> | (fail "Circled Items Must Be Singular")
]
try [thru group! (fail "Only One Circle")]
accept (result)
]
]
>> circled [a (b) c]
== b
>> circled [a b c]
; null
>> circled [a (b c)]
** Error: Circled Items Must Be Singular
>> circled [(a) b (c)]
** Error: Only One Circle
Remarkable plasticity, and I want to see these weapons come to the code golfing field once they are adequately Rebmooshed. 
This example tipped the balance to where I decided that matching <end> should be invisible. Because I wanted a way to synthesize the result while doing the end match. Writing elide <end> is possible, but there's essentially no cases in practice where you don't want to elide the end.
>> parse [1 2] ['1 <end> | (fail "Not a 1 followed by the end")]
** Error: Not a 1 followed by the end
>> parse [1] ['1 <end> | (fail "Not a 1 followed by the end")]
== 1
The previous result was evaluating the <end> to the input position at that moment of being at the end--so effectively a series at its tail:
>> parse [1] ['1 <end>]
== [] ; old behavior...how often would you want this?
If that's what you actually want (which no one ever did) you can can say <end> <here>.
>> parse [1] ['1 <end> <here>]
== []