Bots that are aware of their charge level and plan accordingly.

[ssilk]

I try an short answer:

Adding a reserved-queue will increase CPU cost (one queue per roboport).

[ As reminder: You already increased it a bit because you use the “go to next roboport in my direction”-algorithm instead of “go into direction of my target”, we have discussed that out. Now again a bit more. And this is not where it will end in the end, I predict more such “exceptions”, when we dig deeper.

BTW this is what I call a clear sign of increased complexity ]

Instead I would say from the moment, where their charge goes below 20% the bots should behave like the old bots: Searching (again) for the “next” roboport where they can charge.

[BicycleEater]

Adding a reserved-queue will increase CPU cost (one queue per roboport).

Strictly this could all be done with a counter - every bot knows which roboport it is going to, and increments the counter for that roboport, and decrements it if it changes target. I'd still say it would increase the difficulty of making the game work without bugs.
Again, the overall quality of this system would be something to work out with a prototype version, to see if it actually causes any weird problems.

[mrvn]

Yes, all I mentioned was a counter. And that wasn't part of the proposal as it's not clear if that is needed at all and relies on details of the bot implementation only the devs know. Weather it's needed at all is unclear.

Weather it is even something that needs to be added is also unclear. I would have a roboport already have a queue of bots targeting that roboport, either for recharge or resting purposes, because when you deconstruct a roboport then all bots targeting the roboport change where they are going. Also I wouldn't want more bots targeting the roboport to rest in than the roboport has space. Does the roboport already have such a list or lists or counters? Or do you check all bots for where they are going when a roboport gets removed? That's something only the devs can answer.

There might be more hidden dependencies in the bot code that make the proposal more complex than described, there always are. But that's not something that can't be deduced from playing the game. Nor has it been brought up as reason why this can't work till now.