The resource rule as stated is linear: once you use a resource, you can't use it again. Perceus is not that. Perceus exists precisely because values are shared — it inserts dup/drop and then reuses the allocation in place when the count happens to be 1. If everything in the language were genuinely use-once, you wouldn't need refcounting at all; a linear type system gives you the frees statically. The fact that Perceus is in the design implies aliasing is allowed, which means "one owner" is a description of the socket/interrupt layer, not of memory.
That's fine as a design — but then the elevator pitch is "two rules that rhyme," and the FAQ's central claim ("you only need to learn one rule") is the thing I'd expect to break first under contact with real programs.
Related, and more concrete: Koka and Lean get away with RC partly because their data is overwhelmingly acyclic by construction. Your README shows var bindings and mutable struct fields. Mutation plus refcounting gives you cycles, and cycles leak. What's the plan — a cycle collector, weak references, a type-level acyclicity restriction, or accepting the leak? DESIGN.md would be a good place to state it outright, because it's the first question anyone with RC experience will ask.