Module view 

M.2.b.2 (2026-06-01): create_multibuffer_view — the atomic “make me a multibuffer view” entry point that providers (and tests) call.

Composes the five steps so providers can’t forget any:

1. Allocate a BufferId.
2. Build the typed MultibufferDocumentHandle from sources + excerpts (empty inputs are valid — async providers open empty views and stream content via MultibufferDocumentHandle::append_excerpts).
3. Register the typed handle in MultibufferRegistry (pulled from activator.services()).
4. Insert the upcast handle into BufferStore via H.1’s insert_document_buffer(id, BufferKind::Multibuffer, ...).
5. Activate multibuffer-mode on the buffer via activator.activate_major_for_kind(id, Multibuffer) — H.2’s ModeRegistry::find_major_for_kind resolves the mode id from the kind.

Failures (missing BufferStore / MultibufferRegistry service) log + return early. The activation cascade’s own failure path publishes through ModeEvent::ModeActivationFailed. Return type is BufferId (not Result) to match Editor::activate_major_for_buffer_kind’s existing shape.

See docs/dev/architecture/multibuffer-views.md §3.7.

Functions

create_multibuffer_view

Atomic insert + activate-major for a multibuffer view. Returns the freshly-allocated view BufferId. After this call: