We do all three in different situations.

Can you talk more about that?

I know that when I write a lib I can use 3️⃣ . But for "app logic" sounds bureaucratic use 3️⃣

It really depends on the context and the amount of uniqueness you need/want. Hard to be more precise than that.

The first form tends to be more or less :subsystem/name for things that are unique within a given subsystem but may be exposed to other subsystems (and a subsystem is a collection of namespaces).

The last form tends to be for things that are "local" to a specific code namespace.

The middle form tends to happen when we have data specs that are more or less separate from any code namespace (so they refer more to a domain concept than a specific subsystem on one end or namespace on the other).

Kind of :app/db or :db - Global things. All systems will know about that at some point :app.user/name - Many systems will talk about that. That's my domain. ::my-thing - A local only/closed thing. Just make sense here. ??

That's a reasonable rule of thumb. Like I say, it's all about context and the necessary amount of uniqueness you need for a name.

::my-thing (and ::import/my-thing) have the specific advantage that you can build tooling on top of it. Examples: static checking against typos, go-to-definition, pseudo-docstrings. I have enjoyed all of those in current or past projects

Personally I add snippets (like Emacs' yasnippet) to my editor, that way I can version-control them without polluting projects