Yes it is 138 errors on the megaspeedy upgraded drive.
I think we deduced at the time that the 138 error as reported was caused by changing modes from Stock 1050 to Speedy or vice versa without resetting the OS, but obviously from your description the OS is in fact being reset.
The reason an OS reset is important is that it clears the high speed index table, causing all drives to be speed-polled again. So if the baud rate changes, it will be picked up. This behaviour is the same in the High-Speed OS and the PBI BIOS. The only differences - aside from SIO2BT handling - is the fact that the SIO code in the PBI BIOS has a slightly different calling path than the same code in the custom OS, but this should make no difference to the timing of sector transfers. I have no MegaSpeedy drive here (nor a working 1050, in fact), so I can't really do any troubleshooting on my own. I'd be glad to make any fixes prior to the next update, but for now I have absolutely no clue what could be wrong.
One thing i noticed though, writes to the megaspeedy enhanced drive is slower than writes to a virtual drive at the same baud rate (for example one emulated by a SIO2PC device). Is this normal?
I guess so, given disk access times, etc. As said: I have no way of testing here.
I haven't taken the system apart yet to change out the battery, ProWizard, but it is on my ASTD list, for sure. (A.tari S.tuff T.o D.o)
As I mentioned previous, I'm inclined to think that I did it to myself when I had tried updating SpartaDOS on the U1MB (I thought I used an ATR-based update method, because I know I didn't use UFlash like I did last night to re-flash the U1MB), and that would've been around the same time I began mucking around with the Side/2 that refuses to keep time (see other post) for me.
I forgot to mention that the system also refused to boot to BASIC, even though it was enabled in the U1MB BIOS. That, too, has resolved itself with the re-flash.
I still intend to update the battery, as well and for good measure; but at this point, the issue appears to be resolved and I'll be checking into the Side/2 RTC issue on a separate system as someone recommended in that topic (although the original one I bought works fine in this system, oddly).
The most common problem, I would venture, is a mis-match of main BIOS and PBI BIOS. It's possible to do this if you don't sync updates of all components, or perhaps used some AIO image which possibly had mismatched components in the first place. All the official firmware updates on my site are not only synced, but (for U1MB) include a 64KB binary comprising matching main BIOS, PBI BIOS and XEX loader, and you can't go wrong with that. I suppose corruption of the BIOS parts is possible via a bad SDX flash, but really, if you're getting rogue writes to the flash ROM during an update, it suggests that there's some hardware gremlin at work. And as ProWizard said: software tends not to just "go bad" over time unless something changed or the hardware developed some issue.
Anyway: as I wrote elsewhere today, I'd rather investigate false positive bug reports (especially when the reports are detailed, as here) than miss something that's wrong. It seems the only mystery is the MegaSpeedy issue, which I'd like to figure out before the next firmware revision comes out.