Thanks for the post mchang-r7. When using cloud9 using the src folder, which is a must when working with teams using other IDEs, I find that the key is to have a git strategy that makes sense and then couple it with the force.com migration tool. In this way, you can totally disable cloud9’s syncing and delete their included package.xml (still oddly on api 35).
I always bundle a build.xml file with carefully constructed targets in my git directory so that when I clone it, I have it in cloud9 or any other place I need it. I will also bundle in some bash scripts that make using the migration tool easier. In this way, I can use the migration tool to deploy and compile my code to the Salesforce sandbox of my choice, and also do the same with retrieving existing code from the Salesforce sandbox of my choice.
I’ll typically use the included cli tool in a terminal window to test and debug my code in combination with vim.
In this fashion you can use whatever directory structure you want as long as it is committed to git correctly. Then instead of worrying about where the code is so that cloud9 can sync it, you can simply deploy and retrieve right from your git directory as you would locally. As git is used for teams, then when you push your code and someone else grabs it, it is in the same structure as they would expect.
Hope that was helpful. It is disappointing that cloud9 does not seem interested in solving this fundamental issue with working on teams - which the vast majority of devs do. I have personally brought this to their attention on numerous occasions. Having to hack cloud9 this much makes me a bit wary of it in general, at least at the current time. I think it is designed to connect to an org, grab metadata, do the dev and testing, then push it back up as a single developer working alone. However, many devs need a complete solution that provides more control and a consistent directory structure for their team to share - many team members of whom do not use cloud9. So we have a fundamental design flaw from the outset. It needs to be addressed if this tool is going to have any longevity in the marketplace, imho.