The problem is that DOS is normally single threaded, so the splash screen exits you from your batch routine, and exiting it you might just end up at the command prompt without the remainder of the lines to be executed in the batch triggering.
This is not the problem. I of course mean no offense. I will get to the real problem in a moment. The problem, from where I am standing, has nothing to do with a login splash "eating keystrokes" or an issue with "threading" (I'm not really sure what you mean, tbh, if it was single-threaded one would expect tasks to execute synchronously).
Only way to make this work I think is by creating a TSR service that controls what is launched and when. But the TSR wouldnt be in batch, it would be like C or C++ or another DOS friendly language etc. You would have your TSR load into memory and run thru the batched like routine, and then the TSR can end when completed.
Another solution might be to use CALL to invoke the batch files from DOWNLOAD.BAT, that way DOWNLOAD.BAT doesn't end when NET.BAT does.
Without the CALL keyword, calling a batch file from a running batch file does what is effectively known as "chaining". The first batch file is basically discarded and control is completely given to the new batch file. There is no psuedo stack frame- control does not return to the first batch file.
using "CALL" however means that the batch file will run, and then control will return to the next command in the batch file that used CALL. The way those batches are written now, executing DOWNLOAD.BAT performs none of the tasks in driver.bat or netu.bat because control is passed over to net.bat. and when that finishes executing it goes back to the command prompt.