I've also seen ^gclid= in the past few months - I think from google but can't remember. It's annoying but they are all bigger than we are and it's their ballgame, even if it's our ball. :)

That Click ID is for tracking ads on Bing (same thing with gclid on Google).
It's been that way for many years.
When you land on the target site, code their converts the Click ID to data needed for analytics and attribution.
By converting it to a Click ID, we no longer pass private data (like campaign name) in the URL.

Well, I hope they don't make a habit of it, because I simply block requests with a query. (Except fb-whatsit, which is a known quantity.)

:: poring over logs, where fortunately I find nothing untoward from bing ::

<tangent>
Huh. A certain plagscan.com has been hammering away for the better part of three years--and I never noticed, among other reasons because the request format with ?limit=all would get them an automatic 403 even if header deficits didn't do it. For that matter, what does "limit=all" mean? It's one of those queries that sounds as if it means “Do exactly what you would have done if I hadn’t appended a query at all.”
</tangent>

I simply block requests with a query.

Why what difference does it make?
If your server application doesn't use a given parameters then it's presence in the url shouldn't do anything. If it does do something when it shouldn't, then there is bigger security issue that should probably be solved differently then by blocking url with the parameter.

what does "limit=all" mean?

Really, why bother trying to figure that out, again if "limit" is parameter that you use then you'll know, but otherwise it should be useless.

This is of from the perspective of a developer that has written all the code for his website. If you are using a third party app/CMS (eg: WP) then yes maybe there are some obscure parameters used that maybe unknown to you, but that seems like a really bad design.

I block requests with a query because it's one indicator of malign robots, so it's another way to keep them from slipping through the cracks (header and/or IP). Why should the server be put to the work of looking for a nonexistent file when I can slam the door in their face at the outset. Granted, there are situations where it seems appropriate to return a manual 404, but again that's no more work for the server than a 403.

if "limit" is parameter that you use then you'll know, but otherwise it should be useless

Tell that to the robots who keep asking for it--attached to otherwise-legitimate URLs. Is there something wrong with wondering what a malign robot is up to?

Why should the server be put to the work of looking for a nonexistent file

I get that, but the inclusion of a parameter doesn't mean that the file is nonexistent. If there is a request to www.example.com?some_bogus=param where "some_bogus" is parameter that is not used, then the request should simply return www.example.com. It will not return a 404, by default. This is why FB, Google, Bing et al. use the parameter method of tracking, as it shouldn't impact anything. By blocking request with unrecognized parameters you are potentially blocking a large number of legitimate requests, and that number appears to be increase as this method is gaining in popularity.

A quick check in GA shows that since the beginning of 2022, the number of requests with tracking param such as from Facebook, Google and Apple accounts for the same number of requests for pages as from people using Edge browser. Note, it is likely much greater for sites that get large portion of traffick from social media.

To put this into perspective. In another thread where we discussed the use of Javascript the argument was made that it was absolutely essentially that one provides no-script fallback for user that are blocking JS, even though most estimates set the number of legitimate users blocking JS at well under 1%, >10X less than Edge users. Moreover, the lack of JS is a really good predictor whether user is bot.

Blocked humans can be readily identified because the 403 is immediately followed by a request for the css that belongs to error documents. In fact that's the main reason I maintain a separate stylesheet. To date I haven't seen any human blocked on query-string grounds.

A significant number of querystrings (which I mostly block apart from clickids) comprise code injection attempts and russian advertising (which the damn SEs pick up from somewhere and persist in asking for!). I took some trouble in redesigning some sites to avoid necessary querystrings.

I suspect the SEs' use of querystrings stems from browsers being no longer guaranteed to forward referrers as they used to, so they have to find another method. Hopefully they will switch to the SEC method soon and leave us security-paranoid hosts alone. :(