ok so lets see if I have this completely straight. You are only interpreting between interfaces. Ie calls to and from the keyboard, mouse and screen. The atari code blits the graphics to a psuedo screen which you store in some kind of buffer, translate and then send to the actual screen?
So in which case, the only visual modification that can be made really is by either hacking it.. recognise and intercept a call to something and use other bitmaps to replace them. or by doing minor mods to the graphics before you send them to screen (modify the colours, remove some pixels, etc)
what if in the case of the scull and crossbones I provided for you a smaller image that can replace the one in the game but has those two pixel length offsets? that way by removing them you actually fix the image

That could solve one thing.
the other is the wrap around text. The most basic solutions is to take the text which I think is 6x6 pixels per character calculate the max number of characters with those dimensions on the lower text area and then transfer the remainder of the line to the other line down. What this would mean is for shorter lines you would end up with a space after them but at least you wouldn't lose anything from it being cut off at the right. This suffers though as you have a line inbtween that is shorter than the width of the screen wasting valuable text space.
So here again I will try to give a convoluted explaination of what I think could work without any practical method of execution to prove it would work.. or even work well.
what could be done based on your explaination of copying blocks from the atari virtual screen, is to take the entire block read out the number of pixels width wise as mentioned above and past the cut off point test the pixels contained with the end block. If the values are consistant (in otherwords all black since there is not text) then do not carry over. If there is then carry over. Then test the line below that to see if there is text in the same manner. if there is carry it over just after that last block to fill in the rest of the line and now this one will be shorter so again it needs to see how long it is counting by 6pixel increments and then see if it needs to carry over again and so on. Has that tedium you mentioned before .. but it might work. otherewise you just stop at the first check and people deal with the space lost. Mostly seems to be if then statements could do this.
Additional checks that could be done is the alternate colour (the colour in the blocks other than black) to decide if it needs to be carried up to the end of the line. (BTW I think I'll provide a visual for this since I'm getting confused and I think I know what I'm trying to say) so if there is a line of blue text below a line of yellow text it wouldn't pull the blue text up to sit at the end of the yellow text. Sort of a special case..
need to think more about the rest of it.. :/
(edit)
by the way, what do you meain turning the game sideways does not buy very much? the screen for the atari was 320x200 this screen sideways is 320x240. Thats 320x40 more pixels to play with. The only real issue is making it full screen. how that is done I've no idea.. however Lazy old man said it's been done so at least you know it's possible
moo