I thought I would check in and see if there was any changed behaviour with respect to this bug, and things seem to be worse if anything.
First up, even just with a single tty emacs (i.e. no emacsclient), the minibuffer behaviour has changed, so that now it seems the minibuffer appears in both the tty child frame as well as the main tty frame. Steps to reproduce (again, using my test init.el from OP):
emacs -nw --init-directory=~/emacs-test
M-x emacs-version RET
(Note that when typing emacs-version, there are two visible minibuffers).
Secondly, the two tty behaviour seems screwy, in that the first time a child frame is invoked on the second client, it doesn't get populated/drawn. Steps:
emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version
(note the child frame appears with just the outside border drawn, as shown below)
Third, in a continuation of the two tty scenario, keyboard input (e.g. moving point) in one client instead takes effect in the other client! Steps:
emacs -nw --init-directory=~/emacs-test
Switch to another terminal, side by side so you can see and switch between both easily
emacsclient -nw
M-x emacs-version RET
(runs fine, other than the two-minibuffer issue mentioned above)
Switch focus back to the first terminal
M-x emacs-version RET
(as above, the child frame isn't drawn, but the command itself runs)
Switch focus back to the second client
C-n C-f C-f (etc)
Note that the cursor is moving within the first client. Similarly, M-x opens a tty child frame in the first client even though keyboard input is coming from the second client.