Administrar versiones conflictivas de ruby gems

Estoy construyendo un marco que carga el código rubí proporcionado por el usuario. Básicamente es un mecanismo de complemento. Quiero que el usuario proporcione el código ruby para poder requerir gemas propias. Tengo la intención de que el paquete "plugin" incluya un directorio de proveedores con las gemas.

¿Cómo puedo cargar gemas requeridas por el complemento sin que entren en conflicto con las gemas de mi marco? Por ejemplo, si mi framework usa la versión 1.3.0 de Treetop y un plugin usa la Treetop 1.4.2, quiero que cada uno trabaje con su versión especificada.

Del mismo modo, ¿hay alguna manera de evitar que los complementos entren en conflicto entre sí?

He mirado gem_plugin, _why's sandbox y algunas otras herramientas. Pero no veo ninguna biblioteca que maneje específicamente este caso, supongo que ya se ha hecho antes.

También he mirado las partes internas de Bundler para ver cómo maneja las versiones de gemas. Estoy preparado para hacer algunas cosas bastante complejas si es necesario. Pero todavía no estoy seguro de cómo hacerlo.

También tengo mucha libertad en cómo implemento esto. Entonces, si crees que estoy ladrando al árbol equivocado, dilo.

Gracias por cualquier consejo

NOTA LATERAL: Mientras escribía esto, se me ocurrió que necesitaba algo similar a los cargadores de clases en un contenedor de servlet Java. Un archivo WAR puede incluir archivos jar, y el cargador de clases de la aplicación web preferirá los archivos jar que se encuentran en la ruta de clase global. ¿Hay alguna manera en ruby para segmentar el ruby "classpath" (es decir, load_path, require, etc.)?

Respuestas a la pregunta(2)

Su respuesta a la pregunta