Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

[Linda Walsh]

In another note about different implementations associated
with the pattern "[read[array]] LVALUE [< $(]+ RVALUE [)]?"...

I gave a rough syntax for how I initially thought process
substitution might have been implemented before I got that
it used named pipes (like /dev/fd/99, for example).

repeated, here (minus blank lines) for ref:
>  int savein,saveout;
>  int pid;
>  dup2(0, savein);
>  dup2(1, saveout);
>  int inout[2];
>  #define stdin inout[0]
>  #define stdout inout[1]
>  pipe(&inout,O_NONBLOCK);
>  dupto(stdin,0);
>  dupto(stdout,1);
>  setup_childsighandler(to close 0 when child exits);  #semi-trivial to 
write...
>  if ($pid=fork()) {          #parent
>    dupto(saveout,1);
>    shell("readarray -t uservar("xyz")");   #reads from pipe:inout[0]
>                                            #child handler closes 0
>    dupto(savein,0);
>  } else if (pid==0) {  #child
>    close(0);
>    shell("echo $'a\nb\nc'");   #output goes out on pipe:inout[1]
>    exit(0);
>  }
>  ##parent continues -- no tmpfiles or named fifo's needed.
>  ---------------

As I mentioned, my initial take on implementation was
using standard pipes instead of named pipes (not having read
or perhaps having glossed over the 'named pipes' aspect). 

And, similarly, when using "read a b c" from "<<<(rvalue-expr)" or
<<heredoc...end\nheredoc" -- (*especially* for the 1 line case
like "read a b c <<< "1 2 3"), bash's use of tmp files instead of
a separate process (conceptually similar to the above) and piped back
into the parent (where it would be wordsplit for read or linesplit
for readarray).

In a similar vein, "proga | progb |progc" in some shell implementations
on non-unix systems used '/tmp' files to simulate pipes -- though
most shells today, probably use something akin to pipes.

I thought use of 'tmp' files and such was mostly anachronistic.  I was
wondering if there was something preventing bash from using
plain pipes for both the <<< and the '< <(...)' cases, rather
than relying on 'tmp' files or OS-specific names
(e.g. /proc or /dev .../fd/x)?

Is this a case of it not being done 'yet', or is there some fundamental
reason why they weren't done using plain pipes to begin with?

It seems that having to rely on OS-specific features or external 'tmp'
files makes bash less useful (in a limited OS-support environment where
tmp files and /proc and/or /dev aren't well defined or mounted yet),
more reliant on a specific feature set (/proc|/dev) -- thus more complex
and less easy to port, and not the least of all -- slower and less
able to use multiple threads...

I.e. instead of a=$(cat $(cmd1) $(blah $(nested)) $(cmd3)) having
to use maybe 5 tmp files, and waiting to run each $() in a hierarchal,
linear tree, they could all use pipes and in some cases, run in parallel.

I can't see how that would be any more complex or troublesome
than running "a|b|c|d|e|f", where presumably, all 6 cmds could be
run in parallel and talk w/pipes.

I.e. Is there something I'm missing that would prevent refactoring
the code to use 1 method (processes w/pipes), rather than the
current use of multiple methods that may or may not be working
in some given target env (like early boot where had problems with
both tmp and /proc|dev/fd usage...) or some reduced-function
linux for an embedded system, or comparable?

Is it just a matter of "it wasn't done that way and feel free
to submit patches for consideration...etc?"... or something
else?

To me, it just seems like a 'no-brainer' that going with a
simpler implementation that has fewer external dependencies would
be an all-around-winner for bash, with no downside...I feel
like I'm setting myself up to be shot down, but is there
or are there technical reasons why such shouldn't be done?

*cringing*,
-l