Here is my quick and dirty laundry list of issues that I've been having with MSBuild over the past few days.

• You can't detect which target is being executed, therefore conditional execution of tasks cannot be driven by targets. Instead, you need to start a crazy chain of adding targets and updating properties and adding the new target to DependsOnTargets for the original target. No wonder the build file becomes unwieldy so quickly.
• It is very unintuitive and cumbersome to update property values. If I want to set a property one way in one case, and another way in a different case, it is not easy. Besides, the syntax for the CreateProperty task is way more complex than it needs to be to simply update a property.
• Brutal gymnastics are required to get around customizing build properties outside of the confines of the Configuration mechanism for a given project. For example, let's say I want to change the DocumentationFile parameter used in csc.exe, or change the NoWarn directive. If you're calling an MSBuild task on your solution, you need to specify those command-line parameters as /p: parameters from the command-line or track what you want to do and add the actual command-line parameters to the Properties attribute. It should be as simple as overriding the default build properties that exist in the csproj file, but that doesn't work.
• It lacks a way to list descriptive tags for all defined targets (c.f. "nant -projecthelp").

Apparently, I'm not the only one who sees this as a problem. I think Martin's idea of using a lightweight/script language to control the build is the way to go. Granted, I'm coming to this conclusion 4 years after he is, but the point is still valid today. I'd like to have more language elements in my build process to deal with branch, loop and flow so I can react better than I can with an XML file.

My bottom line: MSBuild may be a good tool for VS.NET to use because it can tightly control the format, but it is not a generic solution for controlling a medium-to-big size build process.