Is there a good way to limit how much is brought to request depot? I have some production that needs very little of some expensive resource. I set 1 drone, but I still get 1000+ of something I would only like to have 10 or so.
Would be nice if you could set max storage on the request depot.

1 drone should only be one stack of the item? are you using other mods?
Also if you need that little, considered regular logi bots if reachable?

Take a look at the discussion here https://mods.factorio.com/mod/Transport_Drones/discussion/5ea46a611aec66000b2333b9

1 drone is only 1 stack in the beginning, but with max bonus it is 6 stacks, and thus a single drone will attempt to keep the resources above 6 stacks, resulting in having 6 to 12 stacks worth of that item in the depot.

for ore and plates, this may be nice (with 20 drones and max bonus having 6x20x50 = 6k to 6.3k ore or 6x20x100 = 12k to 12.6k plates), but at the same time a single drone will fill a science depot to at least 6x1x200 = 1200 bottles, up to max 2400, which may not even be wanted for a 1k spm megabase.

my suggestion to solve this problem was to add a new option to requester depots to "limit drone bonus", similar to the "limit stack size" that inserters have. specifying exact max amounts would be nice too, but on the other hand also take away some of the challenge to balance transports, distances, etc with each other.

just an idea to solve the problem in your (Andrew's) case: connect (by wire) the destination with the supply depot and its inserter and limit input to the supply depot. while the requester has less than one stack (not sure whether it's always 1 stack, or 1 stack times the bonus) it requests any small amounts too. only while above this limit, the requests will be for full transports only.

I do have a mod that doubles stack size and with bonuses it can be a lot.
For example I have setup requesters for rocket silo and build satelite onsite, now I have 600 radars sitting there with just one drone. Even without the mod, it would be 300.
Same thing in my mall, where I only need few of some things (electric engines for example).
Your example would work if supply depot only supplied one area. In my example I have radars supplying my artillery shell cell (btw, I'm playing space exploration, so things are a bit different).

Couple ideas for this:
1. as Anson suggested, checkedbox for "ignore stack bonus". This would ensure you can assign single drone and have only one stack
2. Would be nice to take soem concepts from LTN and have depot take circuit signal where you can set special parameters: storage limit (max & min), priority (would be helpful if you'd want certain production areas to have higher precedence than others), network ID (you could set supply depot & request depot with same network ID and have them work within same network)

additional argument for case 1 : that "limit stack bonus" (if possible, please not only ignore on/off, but limit to a value between 1 and researched bonus, similar to inserters) would not only be useful to restrict capacity for a single drone, but also in several other types of situations, eg on a longer distance where i might want to not get items in huge bursts every few minutes and rather want to use 18 drones for 1 stack each, or 9 drones for 2 stacks each, instead of 3 drones for 6 stacks each) for a specific depot.

having all those settings from idea 2 would be nice, of course :-) but when checking signals all the time in a script is too time consuming, some/most of those settings might also be useful as constants that are settable in a depot gui, besides the bonus also eg the network ID and priorities probably wouldn't have to be dynamic in most cases (which also would trigger recalculation of networks, for even more burden on UPS).

independent from how it is implemented (gui or signals), network IDs might be the solution to some problems i have with buffer and requester depots: two buffers at opposite sides of my factory "prefetch" items, but when one of them runs low or dry, drones start traveling through the entire factory to fetch items from the other buffer which in turn may run low/dry from the additional demand and those drones too will now fetch items from the other buffer depot. it looks cute when watching that busy factory, but like rush hour in real life it can be unnecessarily annoying to have big trucks needlessly go back and forth through the entire city. having a provider set to network -1 ("all/any") and the two buffers with their respective nearby requesters to network 1 and network 2 probably would solve this problem easily, just like the opposite problem of having two ore fields, each with its own local smeltery, which currently in my map sometimes start stealing resources from each other. having one or a few miners and the corresponding ore requesters in one seperate network each, 1 and 2, but both their plate providers in -1 would also solve this problem.

splitting long transport routes into several parts with relay stations between them also would be much easier with separate network IDs which allow for a joint physical road network that has one network ID for each part. currently i have to separate the roads from each other and add multiple transfer stations to reconnect them. the buffer depots are only a partial solution which is only usable when those long routes are split only into two parts, and also only when there are no other buffers anywhere else (eg unusable when there are two distant ore fields on opposite sides of the map). with different IDs, the track pieces could simply be chained with several pairs of providers and requesters.

and as bad and maybe confusing as the "round robin" on the early versions might have been, i now have big problems to give priorities (or at least the same priority) to several providers and ore fields. any additions like networks or priorities could be helpful in those cases too.

no matter what (future) details are, the mod is a lot of fun and very useful already as it is now.
thanks for giving us this completely different alternative to belts, bots, trains, logicarts, etc.