Inline partials vs registered partials: lexical context capture vs global reuse for component libraries

Scenario

A component library must expose reusable UI pieces (buttons, cards, modals) that can be composed inside arbitrary parent templates. Some components need strict context isolation so they only see data explicitly passed to them, while others (like a global header or footer) must be shareable across unrelated page templates without duplication.

Constraint

Inline partials ({{#*inline "name"}}) capture the lexical scope at their definition site, giving automatic isolation from the caller's context unless parameters are forwarded via @partial-block. Registered partials (Handlebars.registerPartial) live in a global namespace and execute against whatever context is passed at render time, making them trivially shareable but prone to accidental context leakage when ../ references reach into the caller's data.

Unresolved decision

No official guidance distinguishes when to prefer inline partials for encapsulated components versus registered partials for cross-template layout pieces. Community patterns diverge, and the choice affects template maintainability, SSR pipeline complexity (async registration), and the risk of silent name collisions in large template trees.

• If the library adopts inline partials everywhere, how do teams share a header across 50 page templates without copy-pasting the definition?
• If registered partials are used for shared layout, what guardrails prevent context leakage when a component inadvertently reads ../user from an unrelated parent?
• Is there a hybrid pattern—registering inline partials programmatically at build time—that preserves lexical isolation while enabling global reuse?