Varias webviews en una ventana
La capacidad que separa de verdad la ventana de la webview: dos documentos independientes dentro del mismo marco. Para qué sirve, qué cuesta, y por qué casi siempre la respuesta correcta es no usarla.
Qué añade
Un documento con dos paneles ya se hace con CSS. Lo que una webview aparte añade no es visual: es aislamiento.
El caso en que hace falta
Es uno y es concreto: cuando parte de lo que muestras no es tuyo.
Una vista previa de contenido ajeno, un panel que carga una página externa, una extensión de terceros dentro de tu interfaz. En una sola webview, ese contenido comparte contexto con el tuyo y cualquier cosa que consiga ejecutar tiene acceso a lo que tu código tenga a mano. En una webview aparte, con su propia capability —vacía, idealmente— está aislado por el sistema operativo, que es la garantía del nivel 4.3.
Fuera de ese caso, la respuesta suele ser otra cosa.
Qué cuesta
Esa última fila es la que decide en la práctica: una API marcada como inestable no es un cimiento. Puede serlo para una parte acotada y sustituible; no para la estructura de tu interfaz principal.
Las dos alternativas
Cuando alguien busca varias webviews, casi siempre necesita una de estas dos:
Un elemento incrustado dentro de tu documento. Para mostrar contenido externo, un marco embebido con sus restricciones de aislamiento resuelve el caso con una fracción del coste, y es una tecnología asentada que el motor implementa desde hace veinte años. No da el mismo aislamiento de proceso, y da bastante.
Varias ventanas. Si los dos contenidos son independientes de verdad, dos ventanas separadas son más simples que dos webviews en una: el sistema se encarga de la colocación, el usuario puede moverlas, y el modelo mental es el que ya conoce. El nivel 12.1 es todo lo que hace falta.
La pregunta que decide entre las tres: ¿tiene que verse dentro del mismo marco, y tiene que estar aislado de verdad? Solo si las dos respuestas son que sí hace falta la capacidad de este nivel.