Sounds like #2 could work if you had some sort of desktop notification system. Then you could write a small script that runs your command line with stdout and stderr redirected to temp file(s), and then alerts you when the process is done, and what the temp filenames are. You could check on your running jobs with 'ps -C scriptname'
Or maybe opens them in $EDITOR...like this (I can't get it to work when $* has a pipe in it, unfortunately)
#!/bin/bash
out1=`tempfile -d $HOME/logs`
out2=`tempfile -d $HOME/logs`
$* >$out1 2>$out2
$EDITOR $out1 $out2 # Replace this with call to notification app and/or logic based on $?/size of $out2
Perhaps you could alias a function that pipes like tee, and checks for errors. Like this:
alias myfunc "errorchecker >& /dev/null"
[command] | myfunc
What it does with those errors is up to you, though your main options are "print them" (in which case, just don't redirect stderr), "log them for fetching" (and write a little command to access & manage the failure reports), or "email them to yourself".
I guess basically what I'm getting at is, look at distributed processing backends such as LSF or GRD for inspiration.
I just went through the following steps recently:
1) Put more things in the background with '&' - but if they have a lot of output they make your terminal usuable.
2) I could ' >t 2&>1 & ' , but then I have to remember to check t when the process finishes, and end up with lots of tiny files everywhere.
3) I could just send output to /dev/null , but then maybe I care what it was if the process fails.