On the other hand, Unity has implemented some basics, which are a real time sink in other engines, outstandingly well.
Lets compare the coding workflow in Unreal Engine 3 and Unity 3:
In UE3 you play the game, find something you want to change. So you shutdown the Game/Editor and go to the code. You code in some immature language called UnrealScript (I think there is a complicated way to use C++ too). Then you compile. Then you startup the Game/Editor again (this is slow).
Also the engine APIs are one of the best software designs I've seen in a long time.
Our teams share code by not coding in Unity projects. All the assemblies are added as plugins with a build script. The games have very little code actually accessible from within Unity. You lose the nice edit and continue, but for a big project with a lot of assets the Unity IDE explodes under pressure anyway.
You don't lose browser support, since what you're dropping into the project is still .NET assemblies (they just happen to have DLL extension). So they aren't any different than what would Unity compile your C#/JS/Boo scripts into.
The main reason I think it's really dumb for Unity to put more focus on high end features instead of polishing and improving what they have is because developers who want those high end features are probably using Unreal or UDK.
The way I see it, Unity's primary market are hobbyist developers or professional developers who are making casual / indie / 2d games, and usually those games are on Mobile. Those types of people want less headaches and they want to be able to do common stuff really really easily. They don't really care about the high end features.
Unfortunately, Unity has terrible built in support for 2d art. Unity also zero built in wrappers for common Mobile tasks like In App Purchases.
Jumping through hoops to get your source control setup properly is a huge knock against it as well. This type of thing should just work out of the box.
You can't cut and paste components between game objects. When importing sounds you have to change the import settings on each sound individually because they don't support multi-object editing.
I use Unity professionally as a casual / indie game dev and while it is the best game engine for me, I can't help but think it could be so much better.
Version control on Unity isn't as bad as you describe. Go to Edit > Project Settings > Editor, then set Version Control to Metafiles. If you have a Pro license, also set Asset Serialization Mode to Force Text. The downside is that this litters your project with .meta files, but that lets you work with external version control pretty easily.
Edit: You should also exclude the Library folder from your VCS, because with metafiles enabled the Library is just a local cache.
You're responding to an argument I didn't make. Version control works fine.
The problem is that there is no method to build libraries and share them between multiple projects, since all the code needs to be under the Assets folder of each project. There is no support for classpaths.
If you update the code in one project, you have to copy the file to the other. Or have some equivalent method of doing so outside of Unity.
Prior to Unity 4, people were using symlinks to accomplish this, but Unity 4 disabled them on Windows to match the OS X behavior (this is described in the post I linked).
Sorry about that, I thought by different projects you meant the same project on different machines. Sharing libraries between projects, now that's an interesting problem. I think I'll go have my morning coffee now.
Thanks for the pointer. I've read a few articles thanks you to. It still seems awfully complex and demands very proficient git usage to do even simple operations. I don't think that's suitable.. but I'm curious are you using it with Unity?
Not with Unity. One big advantage is that git subtree has is that not everybody has to be proficient with it, you can designate someone to set it up and to periodically push the subtrees, and everybody else can ignore it.
That's not quite true; they should split their commit so they don't span trees. But it's not a requirement, it just makes things a lot nicer.
You'll find that the Unity folk disabled symlinks to avoid thorny edge-cases and are trying to figure out a way to give you what you want, including simply allowing sym links but generating a warning message (and Windows devs are suggesting using a junction link -- no clue what that is).
It seems to me that the best option would be for Unity to expressly support the inclusion of folders outside the project tree in projects.
The engine being "six years old" is somewhat beside the point. Major changes and improvements have been made to the engine have taken place, and in some cases these have been as dramatic as "from scratch" rewrites.
The workflow I use is to have my library code in a folder outside of the unity project, and add a build target in visual studio that copies the produced dll into various unity asset folders. Definitely not ideal, but it works reasonably well.