Since discovering the Linux version of the Unity editor was "mainstream" I gave it a right good work out. Initially it did look rather promising, alas it really doesn't take too long once you push things to discover the bugs, currently the assets engine and in particular prefabs definitely have what is basically a show stopper of an issue. Now don't get me wrong Godot isn't perfect, no visual editor for a complex 3d engine is going to be perfect in all circumstances, odd corner cases and unexpected situations are almost guaranteed to highlight some undesired behavior !
By Unity's own admission they only have a small team working on the engine, with the majority of the code being closed source (do they really think they wouldn't get license fees if it was all open source?) You are basically stuck waiting for a small team to fix any particular corner they have painted themselves into.
I did mention that Godot isn't perfect, but lets take the case of what happened to me when I got unlucky! The very first time I decided to use Godot signals it was with the AnimatedSprite3d component and specifically the frame changed signal, trust me to pick the one signal in all the components that wasn't actually firing at all! I was very quickly able to make a minimal project to illustrate the issue, after uploading the project to a github issue within hours someone had made a pull request. Even better the bit of the pull request I was interested in was a single liner, rather than wait for the next point release it was a very simple case of adding a line to the point release source code and simply recompile the whole engine...
This is where open source just beats proprietary software hands down, even the core team for Godot is quite a decent size, and that's not including the literally 1000's of pairs of eyes with access to the source code and hordes of people contributing pull requests...
And speaking of recompiling the whole engine, it's simplicity itself... Godot is using scons, one simple command specifying the number of cores to use and the platform you want the editor for, a little patience and you have a shiny new editor including your hack, why wait for the next point release, fix it and keep hacking - happy days! Obviously if you fix something yourself rather than just patching in a single line from a pull request then you really should make a pull request for it !
The self contained editor binary for Godot in comparison to Unity is basically tiny when compared to Unity which can be 4-6GB per install, and bare in mind you might just need a few different versions of Unity installed depending which show stoppers you're testing for !
I'm still quite new to Godot but here's a run down of a few things that have caught my eye...
Godot is much more forgivable about editing projects, in comparison I once made the mistake of editing a Unity project from a different partition - I wouldn't mind so much but I used exactly the same Unity version, the result was a corrupted project, something that's all too easy to do. Godot projects seem much more robust and many (all?) of the project files are simple text "ini" files, meaning there is the very real prospect of fixing things outside the editor in the event something disastrous happens. In contrast many Unity files are just binary blobs that you can only access via the Unity editor.
While I haven't tried it I see no reason why you couldn't have the windows and Linux version of Godot on a USB stick along with your project files - take it from machine to machine and keep hacking wherever you are, something that is a lot more problematic with Unity.
Scenes are handled a little differently, in the editor you can have multiple scenes open (each gets its own tab) Which is much easier than Unity where you have to just one open scene at a time. Its de rigueur in Godot to use scenes almost like you'd use prefabs in Unity, and you have complete flexibility on how scenes are loaded and what you unload, this all seems to just work in a much nicer way than Unity where scene handling just seems all a little bit clunky, and yes if you want you can just load a scene and automagically have it replace everything in Godot. Currently I'm choosing to load in levels into a separate Node, allowing some nodes to easily persist from scene to scene, do I really want to be updating each scenes "player" node every time I change scenes?
Unity tags or Godot groups, in Unity a GameObject can only have a single TAG, in Godot you have groups and crucially you can have a Node in as many groups as you like, additionally you can even call a method on all group members now just yet I can't think off hand of a concrete use for this really powerful functionality, but I just know I'll be using it in future!
C# or GDscript - while C# is available for Godot, I'm not entirely confident its ready for production use (but you can bet this will change!) and there is a scarcity of tutorials and such for C# in Godot, and if your distro doesn't use specifically the same version of mono you could be out of luck. That said GDscript seems to work well, it has a similar feel to python (I do like indenting for code blocks - forces you to keep code neat!) and I really don't anticipate any speed issues are likely with what should just be game logic. If there is a need for some time critical cpu intensive code, then its always quite possible to compile and link in a library of native code (how well this works when producing binaries for different platforms remains to be seen, frankly I can't see me needing this but its nice to have the option!)
If you're trying out Godot yourself I'd highly recommend you go with the flow and use the GDscript version, its a nice language and there are heaps of tutorials and such for it.
So in a world where nothing is perfect I feel Godot scores very highly if only because its open source and if there is a real show stopper of an issue, at least you have a chance of fixing it for yourself... Generally things seem more convienient (TAGs vs groups, scene handling) in Godot. Given also the things on the horizon for Godot - like a Vulkan renderer and hopefully more work on C# things do look very bright indeed for Godot.
I guess I should thank Unity for being such a horror show, it did make me have a proper look at Godot !