Godot Learnings:

There is no doubt that doing a 3d city game with multiplayer was ambitious for us,
and that's also why we didn't get to play test our game as much as we would've wanted.

But there where (and are) still some Godot related issues we feel this is the perfect time to talk about.

Web / Mobile:

We felt anyone that would play our game in the browser would have such a degraded experience (even-tho the overall FPS was still around 40 to 50 which was fine... to some people (except for when we spawn particles. that would take 3 seconds.)

Since we started using Godot for our game-jams the quality of our games got better then when we ran our own little c++/lua framework. Godot is great for quick polish, quick iteration and we just really like it. But that being said we've always made 2d games. (well mostly) we've done a 3d game in a custom version of Godot 3.4 but web performance was poor. and now we looked at the start of our project, we really wanted to make an FPS, and we didn't want to sacrifice too much. Not being able to host games was a good reason not to release the web build, (yes we have one) but since we would basically fall back to a Forward renderer, and there is no Deferred option, and Forward+ just doesn't want to be a thing just yet for the more common devices. Meaning we would have to strip lights, remove the good fog, global illumination and the resulting game felt flat.

Versioning and UIDs:

We are a team, that work together using git (various clients) and learned that we need a certain workflow to stay productive.
Opening files that somehow reference a *.TRES resource file seems to regenerate its UIDs which then gets serialized with a new ID for everyone all the time. we've done about 400 commits on this project during its 9 day development cycle. for the majority of those we had to deal with the theme and the resource libraries changing without us making a change to them.

Multiplayer Synchronizer & Spawner:

Godot has its head in the right place, it wants to be accessible and easy to use, and in many ways it is!
Once instance of this is the Multiplayer Synchronizer object that you can place under an object, select which variables should be replicated to other clients and tada! it does that.

But then we tried to make a game with it. the proof of concept worked great, (after all why wouldn't it, its basically the documentation)
It only took one item despawning, us wanting to spawn in new items under other nodes to realize this Node comes with a lot of caveats.
1) you need to make sure the node its spawned under is already there on all clients.
2) you need to make sure this object exists until the same time on all clients.

We found that using RPCs was in almost all cases easier, because we could control the flow and see whats  happening directly.
the only trick there was to have the "Server" generate a random string, to set as the new nodes name, then RPC that to all clients to spawn a new instance. This makes sure all clients have a node of the same name, as just calling NewObject would generate different names for everyone. NPC@1 vs NPC@3 for instance. which then would not have RPCs arrive.
With all this funnily enough Multiplayer didn't take nearly as much time as we anticipated.

Grid Maps:

To this day we have a bug where sometimes there are giant holes in our floor.
Its rare, its not something that's synced so any player could have it, or none at all, so one player can just not partake.

Editor:

The idea of having all tools in one place is great. no need to switch context, control schemes etc, and things will work together!
Basic things like multi-line select are things we use on a daily basis for our jobs.
And are lacking or broken. Renaming/Refactoring functions or variables feels like a hassle.

All the extra panels that are open make sure you can really only look at one file at the time.
Looking into Zen mode, we found you no longer know what script file you have open, as scenes will use normal people tabs, but scripts have their own list view which casually gobbles up more horizontal space.

Shader-editor for some reason does not use the same text area, but that area at the bottom where your output gets casually cut off all the time.

After a while scenes start rendering through eachother, having multiple scenes open after doing something you would see the tabs you don't have open behind/through/infront of the one you did have open.

We basically all bound "reload project" to CTRL+R or some version of that, as any time something unexplainable happened,
or something didn't make sense anymore the first thing you want to try, restart the editor, second thing, google it to see if its something in the "Stable" version we're running. (often to find out it was something we did anyway, but the trust was broken)

Conclusion:

We would do it all again, probably the exact same way.