I don't cross shard much, so I may be incorrect. I have heard of a few gotchas when hopping shards.

The biggest being you need to keep your ticks going on both sides to get reliable transfers. An empty shard will often go to sleep and stop ticking.

Another problem is sometime the shards will have difficulty talking to each other. This can cause creeps to stuck in limbo for hours. As far as I've heard they all eventually arrive often in a single clump.

You may have stopped tracking your creeps too soon and the lost creeps are still in transit.

I agree the addition to the return value would be nice. I never pass game objects into a pathfinder. It's always an array of destinations (range,pos) even if it's a single destination. Associating the returned path with index of the destination was straightforward in my case and not terribly cpu intensive. My wrapper then returns the index so my higher level logic knows which target was selected.

It get's a little hairy when the pathfinding fails but that corner case is hard no matter how you handle it.

If the plugin did the index tracking it would be noticeably faster only when there are large number of destinations (>100 i'd guess, but for sure >10). Changing the plugin is a tall order.

Another way to view the API is there are no live game objects, only a snapshot of what internal game object looked like at the start of the tick.
This means using a stale object is totally a thing. A stale StructureController is nearly identical, a stale Creep however is much less forgiving.

The good news is Game.getObjectById is really really fast. So just store game ids and create an object for them when needed.

I love the long lived ruins left over from an abandoned room. It gives an archeology vibe. I'd like to see some even longer back. How cool would it be to find some ruins for Dissi or Atavus.

However, I totally understand about the need to clear ruins out of a claimed room.
How about an API to dismiss a Ruins that only works in claimed rooms. Like how remove() works for ConstructionSites.

The alpha map is worse for colorblind folks as well. On the current map I often can't tell player colors apart. Not a huge issue. The alpha map is worse as I can't tell if a room even has player activity.

I have multiple times thought one of Eiskalt's rooms got wiped. I could only see the roads. The player colors seem deterministic. I think it'd make the players easier to see (for everyone) if the saturation was bumped.

Sorry for breaking the regex thing. I was really hoping they'd keep the regexes and use RE2 to do it safely.

The actual implementation is done completely client side, so RE2 isn't an option.

I hope losing the regexes means we avoid a troll, as opposed to nerfing a feature because of a corner case that will likely never arise (looking at you Intel and Spectre). It would have been a great part of Screeps lore if someone used this offensively, though I could imagine a rage quit over a wipe and no way to view the effected rooms.

How would it cost to import all of a player's market history into BigQuery or RedShift? It'd be cool if the devs supported it directly, maybe charge and access token per year (6 months?).

Another aspect I hadn't considered. Resources all spawn based on ticks rather than time.

Sources:
This could never change. The regen time is too tightly integrated and optimized in creep builds.

Minerals:
Regen every 55 hours instead of 50K ticks. Player harvesting would be completely unimpacted, especially since they already have to adjust to different regen amounts. The sticky part is the ticksToRegeneration property, but I don't think a fuzzy value would break anything.

Deposits and PowerBanks:
From the player's point of view there is no change. It'd be a bit more work on the backend to convert from ticks to time.

It's all a little complicated and the result is not perfectly fair. I'd suggest it isn't worth it unless deliberately differing tick rates was going to be a feature of the shards.

The idea of CPU Unlock fairness brings up a good point. Shard0 is an obvious bad choice for players.

How about fairly refilling buckets based on time instead of ticks. E.g. every 4 seconds add a player's CPU level to their bucket. Now the Devs target tickrate means something in game.

This would balance the slow vs fast shards a bit. It would allow shard0 to deliberately remain slow, or possibly slower (does anyone want 8s ticks with ~double available cpu?). This might enable new play styles, without the disadvantage of losing 33% of your CPU Unlock. (E.g. a player on average would pay for Memory serialization less often on a slow shard).

This would also enable a FAST shard (1 tick/s) without making it cost tremendously more to run for the server. (Per player over head increases, but time executing players' code does not).

Best of all a change like this is nearly imperceptible to the players' bots. Any bot with enough CPU control to notice will also have enough cpu control to cope; it would appear that Memory serialization is taking more or less cpu.

My work around. Loop over all spawns, if they're spawning a creep next tick, hack the creep to disable the notifications. An alternative I considered is disabling notifications whenever a creep has 1499 ttl, but that has slight problems with regenerated creeps and claim creeps.
My point is not that we have a work around instead that my two options are kinda convoluted.

To Tigga's point.
I have twice (I forgot why I decided it was a bad idea) implemented Claim+downgrade instead of reserve for remote harvesting. It's a cool tradeoff (varied solutions, game breadth, etc). But the controller downgrade email spam was too much. There is no in game way to work around the problem. I suppose if I really cared I could craft an email filter to just delete the controller downgrade spam, but yuck.