I'm still feeling my way with the creation of my first module. So far, so good.
One of the side benefits to modules is simplification of lists of global variables, relationships, value lists, calculations, etc. Less clutter, more focus in a complex solution with many parts, as mine already is. Much easier and faster to program within.
I'm using a three letter convention to all my tables, both main solution and modules -- com for company, inv for invoice, etc. Within modules I'm adding "mod" to the end of form names, virtual list names, etc. That approach alone has prevented unique name clashes.
I've also discovered if you forget and actually do call something in the module by a name in current use in the main solution, Servoy will tell you the next time you launch the main solution. So in a practical every-day sense, the imperative for unique naming isn't so onerous.
However I do have one major beef about modules. It's been more than a year since they were introduced and we still don't have an example solution available for learning from. Something simple, demonstrating best practices with considerable commenting within. As a learning tool that's long overdue.
By the way, by experience I can report if you have a global variable in both the main solution and the module, the same value will appear in both. Most likely because there's only one global variable in memory.
I've also been able to navigate back from the module to the main simply by calling on a method located in the main solution which includes a "show form" function.
All this stuff must seem really obvious and junior to Servoy's developers but without an example solution it's hard to build up an understanding of the underlying architecture.
In practical terms, working with modules isn't that difficult -- so far. 
