Very slow to include bigger batch extrinsics that worked fine before

Is there an existing issue?

[X] I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

[X] This is not a support question.

Description of bug

Certain (forced) batch transactions on Kusama, that used to work fine until a few weeks ago, take a long time to be included in a block. In P.JS, one simply gets a red "invalid" message after about 5 minutes of beach balling. When submitting with the Python SubstrateInterface it might take 3 minutes on a fast RPC node, but usually it takes up to 25 minutes!

The problematic extrinsic is a forcedBatch of convictionVoting.undelegate of all the tracks 0, 1, 10, 11, 12, 13, 14, 15, 20, 21, 30, 31, 32, 33. The hash is 0x18043c140201001402000014020a0014020b0014020c0014020d0014020e0014020f00140214001402150014021e0014021f00140220001402210014022200

When the number of tracks is lowered (for example, only 0, 1, 10, 11, 12, 13, 14, 15, 20, 21), the extrinsic with the corresponding hash 0x18042c140200001402010014020a0014020b0014020c0014020d0014020e0014020f00140214001402150014021e00 gets included in a second.

For context, these and similar extrinsics are generated by an app that allows users to manage OpenGov delegations (https://backend-opengov.math-crypto.com/). Many people used that without problems up until a week ago.

If this is an intentional behaviour, it seriously lowers the UX of such batch calls. The batch call is not that big from a user's perspective.

In addition, is there a way to determine a-priori what the size limit is of a batch before this happens?

The problem is not exclusive to this particular extrinsic. In the 1kv community, other people mentioned similar issues with, for example, batch calling staking rewards. The solution there was also to lower the amount of calls in the batch.

Steps to reproduce

See above the extrinsic hashes. They can be sent from any account on Kusama.

paritytech / substrate