There should be no need to add delays in between outputting the characters.  As I tried to explain, the OS takes care of storing echo's output until it has been read. It shouldn't matter if the consuming side takes a while to get done; the OS will happily keep the data in the fridge...

If you still wanted to do what you were trying above, you'd need to add a pair of parentheses around the echos and sleeps (aka subshell), so the collective output would be piped into phylib.  As you have it, only the last echo "r" would be piped.

Compare the following  (I replaced your phylib with a bit of Perl code that also reads 3 chars):

$ echo abc | perl -e'for (1..3) {print "Q$_ -> "; read STDIN,$r,1; pri
+nt "$r\n"; sleep 2}'
Q1 -> a
Q2 -> b
Q3 -> c
[download]

Here, the reading side is slow, but as you can see, every answer still ends up where expected.

The net effect of putting the delays on the other side (in between the echos), will superficially behave the same, but the difference is that the reading end will now have to wait until data becomes available:

$ (echo -n a; sleep 2; echo -n b; sleep 2; echo -n c) | perl -e'for (1
+..3) {print "Q$_ -> "; read STDIN,$r,1; print "$r\n";}'
Q1 -> a
Q2 -> b
Q3 -> c
[download]

I.e., in both cases, there will be 2 sec intervals between outputting Q/A's.

As for phylib aborting after the first input... are you sure it reads char-by-char, or does it maybe read lines (i.e. characters up until a newline)? In the latter case, you'd need to have echo output \n in between characters, or else the entire "rYr" would be consumed by the first read...

P.S.: echo -e interpolates escapes (like "\n"), and echo -n suppresses outputting of a trailing newline (which you don't want in case the program is reading char-by-char).   (Update: at least that's what the bash builtin echo, and /bin/echo on Linux does — unfortunately, different versions of echo are notoriously known for their incompatibilities wrt behavior and options...)