Impact of marking a var private with ^:private on cross‑namespace usage in Clojure 1.12

When refactoring a utility namespace in a Clojure library, a developer marks several helper functions with ^:private to hide them from the public API. The goal is to prevent accidental use of these internals while preserving the existing public functions for consumers.

However, the library is distributed as a JAR that may be AOT‑compiled by downstream projects, and some users have previously required the helpers directly via require or fully‑qualified symbols. The change raises uncertainty about whether the private metadata is respected across different Clojure versions, build tools, and class‑path scenarios, especially when the library is reloaded via tools.namespace or used in REPL‑driven development.

• Does marking a var with ^:private guarantee that any attempt to reference it from another namespace will trigger a CompilerException, regardless of whether the calling code is AOT‑compiled or loaded dynamically?
• If a downstream project has already compiled against the previous public version, will switching to the private declaration cause linkage errors or silent failures at runtime?
• Are there any known differences in how Clojure 1.12 versus earlier releases treat ^:private vars when the namespace is reloaded via tools.namespace or when using the REPL?