Meanwhile it seems to look o.k. for me when I run

rear -d -D mkbackup 2>/dev/null

rear -d -D recover 2>/dev/null

i.e. what is missing is to fix all the old deprecated usage of '>&8'
cf. #885 (comment)

By meditating over the weekend how I could
fix all the old deprecated usage of '>&8'
I think now that I will fix it in two steps:

First setp (within this pull request)
I will simply convert all old usage of '>&8' into '>/dev/null'
because according to
#874 (comment)
all old usage of '>&8' results the same as '>/dev/null'
so that converting all old usage of '>&8' into '>/dev/null'
does not change anything and I can proceed here
towards getting this pull request in a state where
it can be merged.

Second step via #887
As a second separated step I can step by step check
each usage of '>/dev/null' and clean it up or enhance it
as appropriate, i.e.:
usually things should go to the log file but sometimes
things should actually still go to /dev/null, cf.
#887 (comment)

Manwhile this pull request has changed from my initial attempt to
"Use generic ReaR functions for actually intended user input/output"
to
"Redirect both stderr and stdout into the log file
but use the original fds for actually intended user input/output"
which means it already solves
#885
in a (relatively) simple way as follows:

In lib/_input-output-functions.sh I do (excerpts):

# Duplicate STDIN to fd6 ...
exec 6<&0
# Duplicate STDOUT to fd7 ...
exec 7>&1
# Duplicate STDERR to fd8 ...
exec 8>&2

that is sourced before I do in usr/sbin/rear

# Redirect both STDOUT and STDERR into the log file.
...
exec 2>>"$RUNTIME_LOGFILE"
...
exec 1>&2

In all user input/output functions and in all scripts
I use now fd6 for actually intended user input and
fd7 and fd8 for actually intended user output.

To keep backward compatible behaviour
all old usage of '>&8' was converted into '>/dev/null'
where /dev/null usage in general can be cleaned up
later via #887

Because it works well for me and I did not change
real functionality but only whereto stdin and stdout goes
I think this change cannot cause severe issues so that I merge it
(of course if there are issues I will fix them).

In https://github.com/rear/rear/wiki/Coding-Style
I explained "What to do with stdout and stderr" when
both stdout and stderr are redirected into ReaR's log file.

In #1391 (comment)
I falsely assumed this change cannot cause severe issues,
see #1398

So should we revert it?

@schlomo
please have a look at the actual current code what really would
have to be reverted to get back the previous behaviour, cf.
#1398 (comment)

From my point of view all the other changes in this pull request
are valuable enhancements and code cleanup, cf.
#1391 (comment)
for an overview.