Unity needs a Linux headless server build to open very wide possibilities for the indie multiplayer games.
The task seem to be not complex at the first glance (I'm a developer myself):
1) Introduce a NULL rendering device (in other words, Unity3D will not render anything, this could be a trivial task, but depends on how tight OpenGL is integrated into Unity code, first version may use a dummy OpenGL driver to ignore the OpenGL commands, the more robust approach will be to not calling render scene methods, just update the world/physics, no sound driver either)
2) Compile code on Linux (which should compile without major troubles, the Mac version is based on *nix anyways, the only trouble could be the 3rd party libraries, but I'm sure there are binaries for Linux for RakNet, PhysiX)

This headless server will allow to have networking clients talk to the native Unity code, so no custom server coding needed. Seems like all the networking support is already in Unity and this idea seem to be very logical to me.

The possibilities are endless for small indies - multiplayer games out of your browser, Unity3D taking over game dev market, etc

FBX imported meshes are rotated 270 on X, yet are still incorrect. We need FBX imported mesh to be correctly oriented, and without requiring hacks like GameObject rotation. Many formats actually use an FBX conversion during the import process (max, blend).
An alternate solution would be to allow us to configure the defaults for this aspect of the importer however we want, for scale and orientation. I realize we can change these values per-object, but what we really need is the ability to change the default values so that we don't have to manually modify the import setings for each individual file.
Some forum threads on the topic.
http://forum.unity3d.com/viewtopic.php?t=22919
http://forum.unity3d.com/viewtopic.php?t=11004&start=0&postdays=0&postorder=asc

I saw a post about visual GUI editor and shader editor. They are all nice but missing one important visual editor, it's visual logic editor.
Right now there is no easy way to create cut-scenes without scripting, moreover, easy way to visualize what's going on in the scene setup. Scripts are all hidden from the scene and it's hard to navigate through the scripts to find connections between it.

Comparatively speaking, I think shaders are better designed by programmer but creating simple game logics or cut-scenes are better desigend by artists. But once we have game logic editor, similar interface can also be used for the shader editor and such.

This has many benefits: for one, if you could read the input settings, in-game tutorials would be far better. Right now you have to use awkwardness like "press whatever key you have set to the fire button", or else go through the pain of making your own input manager just for this purpose.

Or in those cases where you don't have the built-in input manager and have to write your own anyway (web players, widgets), having access to input settings would allow the continued use of GetAxis and GetButton while being able to allow players to set keys, instead of having to use the less-than-ideal GetKey.

Also, you could change input settings on the fly, instead of (for example) having to create two axis setups using the same keys when you want the controls to behave in two different ways. This is especially awkward because then players have to set the controls twice in the input manager.