mdraid will still, after some 10 years of the bug being known[1], happily corrupt all your data if you mix hardware with different queue sizes.
How do you know you you have hardware with different queue sizes? Why, you start to experience data corruption for no apparent reason, of course. There's no other warning. And the only "workaround" is setting the global queue size to the lowest common denominator of the hardware installed – and God help you if you later install hardware with a lower queue size.
That bug report isn't about data being corrupted due to mixing hardware with different queue sizes. The problem described in that bug is that if you add a device at runtime with a smaller queue size, the queue size of the mdraid device correctly decreases. However, if you have a dm-crypt volume mounted on top of that when you add the device then dm-crypt doesn't have any way of detecting the queue size change and stuff breaks. Just mixing different queue sizes shouldn't cause this, and neither should adding devices to a mdraid volume without anything stacked between it and the filesystem.
Is that bug actually fixed or not? The bug status is "CLOSED CODE_FIX", but commenters in the bug say they still have the problem with kernel versions in which the fix is supposed to be present.
(Aside: I think bug trackers should be configured in such a way that you can't mark a bug as having been fixed unless you specify the ID of the commit in which it was fixed.)
How do you know you you have hardware with different queue sizes? Why, you start to experience data corruption for no apparent reason, of course. There's no other warning. And the only "workaround" is setting the global queue size to the lowest common denominator of the hardware installed – and God help you if you later install hardware with a lower queue size.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=9401