Plugin marketplace needs hierarchical namespacing to avoid collisions across organizations

Problem

Plugin and marketplace names exist in a flat namespace with no scoping mechanism. This creates several problems for organizations running multiple internal marketplaces alongside the official one:

1. Name collisions — Two marketplaces can independently define a plugin with the same name. The first one registered wins silently (see #44042). There's no way to disambiguate.

1. No organizational scoping — A company with multiple teams publishing plugins has no way to group or scope them. You end up with defensive naming (otpl-schema-migration instead of schema-migration) to avoid collisions.

1. No hierarchy within a marketplace — Plugins in a single marketplace are a flat bag. There's no way to express categories, teams, or functional groupings (e.g., infra/deploy, infra/db-migration, observability/grafana).

1. Ambiguous resolution — When the official marketplace and an internal marketplace both offer a plugin with a similar purpose, there's no precedence or override mechanism. You can't say "prefer our internal fork of X."

Comparison

This is the same problem npm had before scoped packages (@org/package), Docker before multi-level image names (registry/org/image), and GitHub before orgs. All solved it with hierarchical namespacing.

Proposal

Introduce scoped plugin names, e.g.:

• @anthropic/jdtls-lsp (official)
• @opentable/schema-migration (org-internal)
• @opentable/infra/deploy (org + category)

Resolution rules:

• Unqualified names resolve against official marketplace first, then registered marketplaces in order
• Fully qualified names are unambiguous
• Organizations can pin resolution order in settings

This would also make enabledPlugins in settings.json clearer — "@opentable/schema-migration@otpl-marketplace": true is self-documenting compared to the current format.

Related

• #44042 — marketplace name overwrites
• #43695 — namespace-qualified skill invocation