recently some discussion here made me thinking if OpenSCAD should split the compiler part from the UI.
There where numerous requests for command line solutions. Others requested ports to other platforms which would require a GUI-framework change (Android, Metro, Web-based solutions).
I believe that a split could enable the main devs to focus more on the compiler, language syntax, math, etc. whereas others resp. new developers might jump in to create UI solutions.
If you check projects like Arduino or Processing, they come with a very basic UI but this does not prevent you to just use the command line tools to use whatever fits your workflow.
Furthermore, I like the way, e.g. matplotlib (a python lib to draw graphs), gnuplot, etc. deals with various outputs. They consist as export modules and you call the exporter function within the code. This is not limited to file-based output but could also just render a window on the screen.
saves the design in an stl file.
draws a window with the OpenCSG object as it happen now in the present UI.
Same for all other existing and upcoming export and rendering options. The import could be handled in a similar way.
That would decouple OpenSCAD from the GUI and people could easily run it headless and within any kind of workflow, be it a webserver, remotely on a more powerful machine, on a different platform, integrated in a much bigger workflow, etc.
I believe that this approach also helps to deal with many other requests. E.g., it should make multi-threading support easier (e.g., it should be easy to run several headless openscad instances each rendering one module or a call of a module).
Furthermore, having defined interfaces for import and export modules makes it much easier for people to contribute new export and import modules. At the same time encapsulating import and export makes testing and bug-fixing more easy too (e.g. you could release a bug-fix for a certain exporter, without the need to release a complete new version of openSCAD).