You can say: The panel provider isn't flexible enough, but limesurvey is lacking a sophisticated passthrough/prefill management.
You often need to use a hidden question (now possible without javascript workaround) to store the panelid and prefill the hidden question via a SGQA identifier (e.g. &1X6X121ab1=Y ). The SGOA indentifier can irritate panel providers because normally they get common short words as variable declaration. The SGQA can be easily overlooked or misunderstood as sessionid.
To implement passthrough/prefill fields a similar approach to "User-defined attribute fields" in the token management would be useful.
The passback to the panel can be tricky because you can only define one offical end to the survey.
The workaround for different exits for different return codes is to use quota. This works as long as the last question allows quotas.
A special questions type for exit/jump url would allow to set different exits with different codes without using quota.
To easily pinpoint problems with waves of test people from panel providers the recording of os,browser,javascript would be helpful.
When using a workaround with a random number which was assigned to a hidden question some surveys weren't correctly filled. I found out that a few browser version were showing this hidden field and people changed the number. This was only possilbe because I used a chained survey which used a different survey tool which recorded the browseragentstring and the javascript version.
I won't recommend a panel provider since Limesurvey still can be used with any provider. They might prefer the two big ones

But to choose a provider because he is "limesurveyfriendly" will hurt your studies. The quality of the panel should be the first criteria.