Pervasive sunyata / flowy logic

Towards [Flowy Logic](https://docs.racket-lang.org/qi/Principles_of_Qi.html#%28part._.Flowy_.Logic%29), here is an example where having it pervasively would lead to better DWIM behavior, without needing to pedantically handle minuscule details that could be handled by a richer logic.

The example is from Emacs Lisp. The specifics aren't essential, but for clarity: we are trying to ambiently record keys pressed during the user's use of Emacs, into a ring data structure, but only if the key event is distinct from the previous one. This is to enable repeating them if necessary without requiring re-entry, and having successive duplicates would not be useful.

```
(when (and this-key-sequence (not (seq-empty-p this-key-sequence)))
(unless (equal this-key-sequence (repeat-ring-last-command))
;; don't record successive duplicates
(ring-insert repeat-ring-recent-keys this-key-sequence)))
```

The problem is that the ring may be empty, and `(repeat-ring-last-command)` might return an error in that case.

One option is to handle that by returning a sentinel `nil` in that case, but that breaks down if in fact the user somehow managed to enter a key sequence that's represented as `nil`. It may not be possible in this specific case, but the point is that we want to design to be agnostic to such implementation details.

So a typical resolution would be to modify the conditional checks here to something like this:

```
(when (and this-key-sequence (not (seq-empty-p this-key-sequence)))
(if (ring-empty-p repeat-ring-recent-keys)
(ring-insert repeat-ring-recent-keys this-key-sequence)
(unless (equal this-key-sequence (repeat-ring-last-command))
;; don't record successive duplicates
(ring-insert repeat-ring-recent-keys this-key-sequence))))
```

Another option is to modify `repeat-ring-last-command` to handle the error and raise a specialized error indicating that the ring is empty, and handle that special error using exception handling.

All of these alternatives seem to complicate the implementation in _pedantic_ ways. It's possible there is a "clever" way to write this succinctly, but such cleverness also isn't the point. Rather, we seek to probe what can be expressed precisely, not select preferred ways of expression.

Instead, using sunyata, and the prescriptions in the Qi docs, `repeat-ring-last-command` would return _nothing_. Then `(equal this-key-sequence )` would return _nothing_. The `unless` (like `if`/`when`) is specifically looking for a truthy value. Since it gets nothing, the predicate is not satisified. It would function the same as if it received `false`, as that, too, is not truthy.

The question isn't of a superficial nature regarding shorthands, but about weaving a richer logic into the fabric of our programming language --- truth, falsity, arbitrary values, and nothing --- for a more precise and less pedantic way to code.