We introduced the concept of vscode.NotebookKernel previously to allow multiple notebook execution contributions and the responsibilities of Content Provider, Renderer and Kernels are much more clear. The proposal we had was a provider like kernel contribution:

export namespace notebook {
    export function registerNotebookKernel(
        id: string,
        selectors: GlobPattern[],
        kernel: NotebookKernel
    ): Disposable;
}

Extensions can register kernels for specific files (filtered by selectors: GlobPattern[], e.g., *.ipynb), it works fine for simple cases (like GitHub Issue Notebook, which only has one kernel for all *.github-issues files). However it's not clear how multiple kernels contribution really work with this API, here are scenarios we need to take into accounts when polishing the design of the kernel API

• Kernel registration
  • Dynamic multiple kernel reigstration. Current kernel registrations are static (through contribtions in package.json) but sometimes extensions can know what kernels are available only after it's activated.
  • How are we going to support kernels per document?
  • Event for available kernels change
• Kernel activation
  • Some kernels need to be activated before the first execution (e.g., jupyter kenel with ipywidgets support). We might want to introduce an activation method for the kernel, resolveNotebook(document: NotebookDocument, webview: NotebookCommunication): Promise<void>;
  • If users switch kernels, is previous kernel still active? Should we kill/interupt the kernel?
• Kernel picker & active kernel indicator