this doesn’t make any sense to me
first, I think we MUST know for which combination of ArduCopter firmware version and STorM32 firmware version a certain observation is observed. Otherwise discussing a observation is useless.
I say this because I know for a fact that there had been combinations of ArduCopter and STorM32 for which the behavior was not at all like you describe, and in fact were working (except maybe that some signs were not correct). Sadly I can’t say myself which combination(s) this had been, since that’s quite some time ago when I did that testings. I also might not have tested the serial well, so I may speak only for MNT_TYPE 4, but I do speak for at least one MNT_TYPE.
I thus do not think that the above is a representative reflection, but either is maybe a Solo issue, or something important has changed in ArduPilot in the last year (I remember e.g. that a year, or was it 1 1/2 years, ago, with Mavlink2 coming, all sorts of problems occurred because the Mavlink2 implementation wasn’t fletched out, don’t know what has happened since then and if that ever was weeded out, Francisco/Oxinarf and Luis/Lvale had been involved in that discussion at the time)(I also remember that about the same time - at the request of ArduPilot devs - I made the recognition of Mavlink messages more flexible, conforming to the “standard”).
Your bullet 2 I would think is a smoking gun demonstration of a bug (or several) in the ArduPilot firmware … with STorM32 heartbeats disabled it really doesn’t do much. You probably could disconnect the STorM32 and would see the very same malfunctions.
Also bullet 1 should make you wary.
Btw, you know that you can disable the emission of the STorM32 gimbal attitude data, which would allow you to test your speculation in bullet 1.
Again, you maybe want to try betacopter and see how it does.
I think one also should settle on one MNT_TYPE and concentrate on it first.
My 2 cents. 