A plugin component (e.g. a custom field input) rendered inside the relation edit/create dialog (RelationModal) can't determine the document it actually belongs to. unstable_useContentManagerContext() resolves id/model/collectionType from the URL (useParams), so inside the dialog it returns the parent/page document - never the entry being edited in the dialog. As a result a custom field can't tell whether the dialog is creating a new related entry or editing an existing one (both report the parent's id).

Core already solves this internally with useDocumentContext() (prioritises the relation-modal scope, falls back to the URL), and the built-in UID field depends on it - but useDocumentContext / useRelationModal are not exported. The public surface only offers unstable_useContentManagerContext, unstable_useDocument, unstable_useDocumentActions, unstable_useDocumentLayout, useDocumentRBAC, so third-party custom fields can't reach parity with core fields.

Ask: expose the modal-aware document context to plugins - export a (stable or unstable_) useDocumentContext() returning currentDocumentMeta, or make unstable_useContentManagerContext() reflect the nearest document scope (relation modal first, then URL).