Docs: How to understand JGrass's console engine - part I, a boring introduction

I was asked many times about the link between JGrass and GRASS. This could be one answer finally.
In the past JGrass was trying to wrap GRASS in the sense of user interface, i.e. GUI, and that was all. Dark periods of JNI and heavy maintainance horrors signed those times and the chosen java platform portability was often gone with the wind.

So we decided to make JGrass an I-can-live-also-alone entity. The material was there, since JGrass is heavily sponsored with knowledge by Riccardo Rigon's research team at the University of Trento, faculty of engineering.

So we ported to pure java some small I/O parts in order to be able to read GRASS's workspace and raster and at that time vector data (new vector is not there yet). That was a good choice, since it made us independent from the operation system and etc. etc. etc.

Also in the new JGrass, as of what we are trying to do with the marriage with udig, the analysis engine of JGrass has been extracted and isolated to what we called the console engine. This engine is able to add calculation power to JGrass, as well as beanshell scripting and scripting in the "JGrass modelling language". The important thing of this engine is that it is also able to live in standalone modus and also that it can launch GRASS native commands. So yes, that is the interaction between JGrass and GRASS. JGrass works with the exactly same environment and puts efforts to stay compatible with GRASS, and it can execute GRASS commands mixed up with scripting and JGrass commands.

How to do that?
Alright, the steps are probably more than one:
1) where does the console live?
2) how to use it?
3) how to use it without JGrass?