Linux -- Redirecting inputs -- same stdin for 2 processes

Just for fun, we tried to execute commands on multiple terminal.
For this, we made a demo.
Lets say, we have pts1 and pts2, which are pseudo terminal connection from 2 ssh clients.

We connect to pts1 and run the following;

bash < /dev/pts/2

So, we redirect pts2 to our bash shell running on my pts (pts1)

So whatever we write to the terminal of pts2 is displayed and executed in pts1..

For example, we write "ls" in my terminal which is connected to pts2, the ls command runs in pts1 and displays the output in pts1.

So far so good. But there is a problem in here.. That is; . The first character/and sometimes the first word, is never catched by pts1.. So for example to write ls and execute it in the /dev/pts/1, we write "lls" in to my /dev/pts2 terminal. Because the first "l" is not catched by pts1, and also it is displayed in pts2.. so lls -> transfferred to the pts 2 as "ls", and ls command is executed in pts1 , as expected. 

Another example of the behaviour is as follows;

We write ls and press Enter -> it s executed in pts2 (where we write)
then, after pressing Enter ;
We write ls again and press Enter -> it s executed in pts1 (as we want)

It seems pts1 has pts2's input as its input(redirected)
and
pts2 has also its own input.
So pts1 reads the input of pts2 , and pts2 also read the input of its own..
So this may be the race condition.

So there seems to be a race condition occuring, but as the input is divided in a systematic way, this should not caused by a race condition, but an algorithm.

To have other opinions, I have started a discussion in Linkedin Group named  Linux Expert.

(Also , started a discussion in http://www.linuxforums.org/  , but it could not get answered.)

By the comments of other engineers in Linkedin, we have conclude that this behaviour should be caused something works in a Round Robin fashion.

It seems, when the stdin devided into 2 processes and the Kernel handles the inputs with a round-robin fashion. Ofcourse the problem is not solved

 it can not be solved, it works that way by design. 

On the other hand, we have found the reason for this at least :)

A suggested method can be using -> script /dev/null | tee -a /dev/pts/2

script makes a typescript of everything printed on your terminal.
Tee command is used to store and view (both at the same time) the output of any other command.
tee -a appends the output to file or typescript, retaining the prior contents.

/dev/null is a virtual-file that can be written to. Data written to this file gets discarded.

So the explanation of the command  above is ;
whatever we write is reflected to the /dev/pts/2 instanty.

Yes, this may be an alternative.. This command will write all the commnands which are inputs of pts/1 to another terminal which is pts/2 in this case ... But it works a little different than "bash < /dev/pts/2".

By using command "bash < /dev/pts/2" , what we do is that, we manage pts2 as another independent terminal, but we able give its inputs from another terminal.. 

On the other hand, the command "script /dev/null | tee -a /dev/pts/2" clones what we write to the terminal pts/2.  So we have 2 terminals executing and displaying the same outputs at the same time.. a Anyways, using script commands  is handy and meet our requirements ,as  we were trying to execute commands on multiple terminals .

POC:
:)