The main objection relates to the fact that MESS emulates the behavior of the real hardware, and the real hardware does not behave in this manner. (Indeed, it's likely not possible on the real hardware to do it even with added hardware).
I understand that, and being a cultist of one specific vintage machine I agree that the machines should be emulated as accurately as possible.
Anyway, MESS
already offers a bunch of capabilities ulterior to the original behavior of most of the emulated machines: state (snapshot) saving and loading; generation of .WAV file for cassette output (instead of just the sound); pausing; usage of keyboard as joystick; the very ability to paste text into the emulator as fast typing; selecting or disabling color artifacting effect; changing of RAM bytes (via the debugger); and so on.
What I am proposing (at least the part of it that relates to BASIC programs) is nothing so alien to the machines' behavior. It's just a more (much more!) convenient way to inserting and retrieving a program into/from the machine.
I have analyzed the cassette output of MC-1000 and created tools for the PC to generate a .WAV file from a text file containing an BASIC program and vice-versa. But the process of saving the text file, switching to the Command Prompt, run the converter, switching to MESS, type "LOAD" <enter>, mount the .WAV file,
play it and wait for the program to load... although much faster than typing it directly into the machine, is still very time consuming for my busy days.
Also, any such hacks will be by nature very fragile and will break each time we update the emulation core in the future.
How so? As I imagine it, for pasting, the MESS core would interact with the operating system and get the contents of the clipboard, and only pass a string to the driver; the driver (who owns the know-how) then tokenizes the program and puts it in the right place of RAM. For copying, the driver would produce a string with the source code of the program and pass it to the MESS core, that would simply pass it to the operating system's clipboard.
Since the core is just a "pipe" in the copy/paste process (as envisaged above), and this "pipe" function is independent of the rest of the emulation, I don't see how a change in other core functions would affect this feature.
