I can tell that you don't understand the nature of the question yet you repeatedly insult me and steer the discussion off-topic. Should I assume that your personality is the same offline?

I am acting in good faith here, and I'm doing so because I think you are too.

I find i interesting that the FIFO queue point, of all things, is where you suddenly reach your end, and respond solely with an actual ad-hominem attack that you clearly hope would shame me out of continuing. A point, I might add, where I did not insult you, did not do anything that could possibly be construed as trying to pull the thread off topic, and where, if I didn't understand you, then you should probably have a long, hard think about whose fault that actually is.

I can't follow you, but anyway, a process can block the next/previous process in the chain, and it is not related to the kernel, os or bash, it just depend on how those processes were designed/implemented. As usual, the performance of the entire chain depends on the weakest link.
No, I don't think Dugan meant to insult you. In fact, I'm quite sure of it. Better to say your statement was surprising. Also you should not deal with the person, but with the answer.
If you think your post was misunderstood please try to explain it better.

You can read about pipes for example here: https://en.wikipedia.org/wiki/Pipeline_(Unix) and here: https://en.wikipedia.org/wiki/Named_pipe. The latter explains the differences between named and "anonymous" pipes.

(Gentlebeings, let us please just remain "on point." If you have anything else to say, that's what private messages are for.)

Now ... "There is no 'chain.'"

As I said earlier, the shell creates a series of independently-running child processes, and connects the STDOUT of one of them – by means of an anonymous "pipe" – to the STDIN of the next. "That's it." Then, it goes to sleep and waits for all of them to finish.

The "flexible hose" of the "pipe" construct does the rest of the magick. Both readers and writers might sometimes be "blocked" if the pipe is (respectively ...) empty or full, but all of the messages will get through. The nanosecond-to-nanosecond sequence of events is entirely unpredictable. The shell process plays no part at all in it – it is asleep until notified that all of the children have ended.

(Also: none of the child processes actually know nor care that their STDIN/STDOUT/[STDERR] streams are actually connected to "pipes." They neither know nor care that they are from time to time being "blocked." All they know is that eventually they will encounter "end of file," just as they would in any case.)

Yes, that is not an official designation of anything, just we used to say the construct of "several commands connected with pipes" is a chain.
see for example here: https://www.howtogeek.com/438882/how...ipes-on-linux/

Yes, I am familiar with that colloquial terminology, but I wanted to explicitly clarify how it actually works. The shell "sets up all the plumbing," then goes to sleep. The pipes then simply work as they always do.

Yes, I totally agree with you (hopefully it's clear to the OP now).

Just want to make clear that I had not posted anything off-topic. I have instead been extremely generous and given you a wealth of relevant information. Information that you needed to know to understand your question. If you failed to recognize that, then, well, the old proverb about horses and water applies.