[Android Q&A, Help & Troubleshooting] sigprof:
Exactly which FOTAFLAG.img did you flash? If it was a dump result, it should do nothing (the FOTA update flag word is immediately erased after update). Maybe just something took effect on the phone reboot.

I looked at the differences between the studypara contents sent during the flashing process, and data dumped from mtd9. Seems that most differences are as follows: in every 2KB (0x800 bytes) block there are 4 extra bytes inserted at offsets 0x200, 0x404 and 0x608, and 12 bytes at the end of the block are lost; there are also some corrupted bytes apparently at random positions. These differences look suspiciously similar to the actions done by this APPSBL code change (it is for a completely different device, but the code seems to be present in our APPSBL too) — modem partitions use pure 512-byte blocks, while apps partitions use 512+4 bytes, and maybe ECC does not work properly too due to different settings, which then causes random bit errors. Therefore probably studypara partition on this phone should not be written with dd or fastboot, except maybe with

fastboot flash STUDYPARA studypara.img

(with STUDYPARA in upper case, so that it would be handled like a modem partition) — but we do not have a proper dump for OT-990A anyway.

If you have Windows XP, you could try to create a full dump of firmware flashed by OTU, which should contain a good studypara image for your phone model:

Download SniffUSB 2.0.0006 x86 Edition from here (this version worked for me; SnoopyPro did not work).

Ensure that you have at least 3 GB free on C: (the log file is written into C:\WINDOWS\UsbSnoop.log, its location cannot be changed, and my log was about 1.6 GB).

Connect the phone without battery with Home pressed.

Start sniffusb.exe; allow it to copy sniffusb.sys and install the driver.

Find the USB\VID_05C6&PID_9002 device (ALCATEL HS-USB QsBLoader 9002) in the list, select it and press the Install button.

Disconnect the phone, then connect it again with Home pressed (it is safer than using the Replug button).

Press the Refresh button in SniffUSB; you should see that the log size is not -1 (device detection traffic is captured too).

Run OTU to reflash the phone.

When OTU completes flashing, disconnect the phone, then copy C:\WINDOWS\UsbSnoop.log, compress it (my 1.6 GB log became less than 200 MB compressed with 7zip) and upload it for analysis.

Finally check the "List devices not present" option in SniffUSB, find the USB\VID_05C6&PID_9002 device (ALCATEL HS-USB QsBLoader 9002) in the list again (look for "Installed" in the "Filter installed?" column), select it and press the Uninstall button (so that further OTU runs will not create a huge UsbSnoop.log).

This should not happen — while OTU overwrites the recovery partition, just flashing studypara should not change it. And flashing FOTAFLAG should not change recovery even if it triggers a FOTA update — this is the list of partitions which can be updated with FOTA:

1 QCSBLHD
2 QCSBL
3 OEMSBL
4 AMSS
5 APPBOOT
6 APP
7 FOTA
8 STUDYPARA

However, there is another thing which could overwrite the recovery — the /system/etc/install-recovery.sh script installed by the official FOTA update.zip; it has some SHA1 checks, but maybe they do not work properly. I think that /system/etc/install-recovery.sh and /system/recovery-from-boot.p should be removed from the system partition if such files are present.