Q:

Why does "metacity --replace" hang my system, but "metacity --replace&" is fine?

The following applies to Lucid 10.04
It happens on my "real" computer and also in a VirtualBox VM...  
(UPDATE) I just now installed Maverick 10.10 to a VM... and almost the same thing happens!
I do have keyboard control (initially) but the only way I can exit the terminal is to close it with the process still running (or Ctrl+C), and this causes the lockup (pressing Enter doesn't take it back to the prompt)     
$ metacity --replace 

The above command (in the terminal) causes my system to hang, every time.  
The command does not return to the prompt.
The window decoration disappears (maybe because the command hasn't completed?).
The keyboard becomes non-functional, (but the mouse still works)... 
However, the following commands work fine, every time.  
$ (metacity --replace &)
$ metacity --replace &    # this works too   

It may "hang" only in that I loose the keyboard, and so can't press Enter to bring it back to the prompt, (...as I have noticed is the case with some unrelated commands which don't "fully" return to the prompt, until I press Enter)  
What's going on here?
My "host" OS is not new, but the VM is in mint condition (almost)... and they both exhibit this keyboard "lock-up".   

A:

Pressing Enter doesn't return to the terminal prompt because metacity is running in that terminal.  Any warning/error messages metacity produces will be printed there.  This is standard behavior for any GUI app.  If you don't want them to take over your terminal session, use '&'.
About the rest -- disappearing window decorations etc. -- I'm baffled myself.  

A:

Running metacity --replace does not make it run as a daemon. If you hit Ctrl-C or otherwise stop that metacity process from running (closing terminal would do that as well), you will be left without a window manager. That is why you lose your window decorations. I am not exactly sure why the keyboard stops functioning (my guess is that once the window manager is closed new updates to the window, like typing, won't be painted to the screen), but I have tested this and if you hit Ctrl+Alt+F1 you can still drop to the framebuffer. Clearly the keyboard has not stopped working entirely, in fact if you click a menu item in gnome-terminal you can use the up and down arrows to navigate it.
You should run metacity in a wrapper, such as screen, when you need to start it from terminal and then close the terminal window you used. Just run screen metacity --replace and press Ctrl+A+D to detach from the screen process.

