Re: loading a program in the background, that only makes sense if you only have one instance of a shell. As an example, my Pi based Internet Radios don't run a GUI. So each program that needs to run must run in the background, so the next will still be loaded and run.
So (as far as I can see) you can load several programs via different Shells from your Gambas program, and they won't block or inhibit the others.
One thing is clear, and that is that this is not a trivial application. So with that in mind I'm going to ask you to fully check your requirements and assess whether you are taking the best approach. Obviously its your choice how you do this, but I don't want to give advice regarding a possibly flawed approach.
Q1: Why do you want a separate program to perform this printing process?
Reason for question: It looks like you only want to print...when you want to print.
If you launch a separate program, you may need some kind of feedback to ensure that it is still running. You may end up checking its running each time, then restarting it if its not, then sending data to print. If that's the case (and you still want a separate program) you could just call it when you need it (via Exec or Shell) and let it close gracefully when its finished.
If you just want the code to be modular, have you considered just putting the printer code in a Module, creating a Class or creating and using a Library?
Like I say, its better to ask these questions now.
Incidentally, the only time I've found the need to create 2 Gambas programs to work together was for my bat call capture software. The first program had to take a quick decision on whether an audio stream contained ultrasonic signals, and then buffer each 'good' file. While the second had to go through each file and determine whether it contained a possible bat call or just other noise. So each file was either saved (along with analysis data, including frequency) or deleted. As the bats could make the sounds much faster than Gambas could classify them, I needed this 2 program (multi thread) approach.