Here is something else that might be unexpected. Change the line to
write(fd, "(a, t10, a)") "1234"//repeat(achar(10),5), "0123"
With ifort, there are four blank lines and the last “0123” is written starting at column 1. Then if you change the repeat count to anything between 5 and 9, you will get that same output, four blank lines and then the string written starting at column 1. The T10 is repositioning the file pointer back to within the previous records and overwriting them with the “0123” string. If the repeat count is larger than 9, then some newline characters are still in the buffer, and they end up being blank lines after the “0123” string.
In contrast, gfortran writes out all the blank lines, and the last “0123” string always starts at column 10.
 I found this text in section 13.7.4 of the f2018 draft (I added the bold):
“If the file is connected for stream access, the output may be split across more than one record if it contains newline characters. A newline character is a nonblank character returned by the intrinsic function NEW_LINE. Beginning with the first character of the output field, each character that is not a newline is written to the current record in successive positions; each newline character causes file positioning at that point as if by slash editing (the current record is terminated at that point, a new empty record is created following the current record, this new record becomes the last and current record of the file, and the file is positioned at the beginning of this new record).”
My example above hard coded the achar(10) character, so it is not required to conform to this paragraph, but I compared the output of new_line() and it is indeed the same as achar(10) for gfortran and ifort, so in that roundabout way, that is supposed to be the behavior. That suggests that gfortran is behaving correctly in these cases with embedded nl characters and that ifort is in error. Here is an updated version of the code that should conform on all compilers:
integer :: fd
character, parameter :: nl = new_line(nl)
open(newunit=fd, file="test.stream.txt", access="stream", form="formatted")
write(fd, "(a)") "1234567890123"
write(fd, "(a4, t10, a)") "12", "0123"
write(fd, "(i4, t10, i4.4)") 1234, 0123
write(fd, "(a, t10, a)") "1234"//repeat(nl,10), "0123"
end program tabformat
I’m running this on MacOS, which is posix compliant, so the records in a formatted file are indeed separated by single achar(10) characters. It would be interesting to see what happens in the output file on a nonposix machine like Windows. On Windows, I think there should be two characters (a cr and a lf) written to the file for each achar(10) character transferred. Can a Windows programmer confirm that that happens?
[edit 2] I have now tested nagfor, and it does the same thing as ifort with embedded newline characters. So if gfortran in correct, then both ifort and nagfor are wrong in this situation.