Gutenberg can be used as a platform/framework to build block editors. Mainly thanks to the @wordpress/block-editor package. That said, the experience today is not as straightforward as it can be. There can be a lot of small gotchas and hacks you need to do in order to achieve the desired result. This issue is going to serve as an overview issue to collect and fix all these issues.

• Peer dependencies: Installing the @wordpress/* packages using npm shows a number of warnings due to unmet peer dependencies, with the latest updates to npm, we should make sure we're using peer dependencies properly. For instance it seems that React shouldn't be a peer dependency for us but instead a real dependency of @wordpress/element since this package is supposed to be used as a replacement for React.
• We use process.env.something in a lot of places in Gutenberg codebase. All JS environments do not provide these, for instance Vite relies on import.meta.env instead. We need to at least not break the JS execution if process is undefined. Assess whether import.meta.env is a better alternative these days.
• There's some weird focus styles by default in the RichText elements, Maybe some reset CSS need to be bundled by default in the @wordpress/block-editor stylesheet.
• Render a <BlockEditorProvider><BlockCanvas /></BlockEditorProvider> should be enough to render the most basic block editor. Today, we're forced to render a number of wrappers and providers or else the experience is broken. Find a way to bundle these providers or make them optional (bundle them if the provider hasn't been rendered already)
  • <BlockEditorKeyboardShortcuts.Register /> Register the block editor keyboard shortcuts automatically when using BlockEditorProvider #53910
  • <WritingFlow> BlockEditor: Add BlockCanvas component = Iframe + BlockList + WritingFlow #54149
  • <ObserveTyping> Bundle ObserveTyping within the BlockList component #53875
  • <Popover.Slot /> Components: Make the Popover.Slot optional #53889
  • <ShortcutProvider /> Make the shortcuts provider optional #54080
  • <SlotProvider /> Bundle SlotFillProvider within BlockEditorProvider #53940
  • useClipboardHandler and CopyHandler Bundle the block copy handler within the BlockCanvas component #54207
  • useBlockSelectionClearer and BlockSelectionClearer Bundle the block selection clearer hook into the BlockCanvas component #54209
  • useTypewriter and Typewriter (check if we should bundle or not)
• Rendering the block editor requires including the stylesheets of a couple packages at least (@wordpress/components and @wordpress/block-editor) even if we're not directly depending on one of these packages (components). Is there a way we can auto-inject these styles while style producing valid npm packages. If not, clarify the documentation.
• The block-library package provides a set of core blocks to be used by third-party block editors. The problem is that the package doesn't make a distinction between WordPress specific blocks and generic blocks. And even for generic blocks, there might be WordPress specific features. Find a way to clarify which blocks are generic and independent of WordPress and which are not, provide a way for platforms to provide platform specific behaviors on top of core blocks.
• A lot of recent features of the block editor (theme.json and block supports) rely on server side rendering to generate the frontend styles, even for static markup and static blocks. This means that our serialization function (serialize) doesn't produce an HTML that is ready to be rendered. Provide a way to generate the final HTML including styles (some kind of render function) that can be used by third-party editors. This code already exists and is being used to generate these styles in the editor, but we should make sure to document properly for third-party usage. Block supports and dynamic rendering in JS and PHP #54047
• We have a guide to build a custom block editor in the handbook, the guide is tailored towards custom block editors within WordPress which is a small set of third-part block editors, should we consider a dedicated website for "Gutenberg as a Framework" which could include a way to build block editors in any JS application, build universal block types (block types that are WP independent)... Bootstrap a documentation website tailored towards the usage of Gutenberg outside WordPress #54375
  • Start a new documentation website with a "Getting started" guide for usage of Gutenberg as a framework
  • Fill all the documentation pages
  • Improve the design of the home page
  • Deploy the website
• Undo/Redo is bundled into core-data making harder for third-party block editors to use, they have to implement their own implementation. Extract that into a reusable package and offer docs on how to hook it with the block editor. Add useStateWithHistory hook and use to show a block editor with undo/redo #54377
• Simplify React usage and reconsider the @wordpress/element abstraction. Reconsider @wordpress/element as a React wrapper and use React more directly. #54074
• Color palettes not working properly in the editor Gutenberg as a Framework: Colors Styles not generated properly in the editor #55036
• Provide sane defaults for all block editors https://github.com/WordPress/gutenberg/pull/56483/files#r1403583859

cc @WordPress/gutenberg-core