You are quite correct, file copied to a floppy without s-seq does not give the bug.
Same file when booted from harddisk-directory without s-seq does.
Attached the bootfloppy used, both versions work fine when run from floppy. You seem to have found it already, I can only think of some code from boot to cli window or some ENV: thing. I will try mocking up a harddisk-directory with only those 2 files and go from there.
Edit: OK, tested and it appeared again when I copied the S: directory to the new harddisk-directory. I renamed startup-sequence to zstartup-sequence, no change. Will report back, just thought you wanted the info asap.
Edit 2:
Removing S:Asm-One.pref fixed it! How the same Asm-One binary handles it differently on a real Amiga is a good question.
Copied the suspect Asm-One.pref file to CF card. Result: works fine in real Amiga, Asmone 1.02+ and 1.20, in WinUAE it works fine in 1.20 but not 1.02+. All tests are without s-seq.
Attached binary+pref file, if you want to find out difference in execution on Amiga vs. WinUAE. "No" combo of settings [in a recreated pref file] fixed it, as soon as a .pref file exists, you get this artifact. [Same thing worked in 1.20 so problem is only in this version] I suspect it either reads the file differently, or memory allocation is slightly different in WinUAE vs. Amiga (or patched to make software more compatible and it didn't work out for this one - except with kick 1.3). Because it alloc/deallocs each time you toggle editor/console, IIRC.