The name is used in templates as well (context class name for EF for example). This would be a problem with '.' characters, hence the clean up.
We'll look into a way to keep the dots for project name only. As the vs.net project file is created in a specific task performer, it's should be doable, we'll report back to you in this thread if we have news.
(edit) We've made a change so we can obtain the 'raw' name for filename creation instead, but I don't know ... it's messy. For the vs.net projects it perhaps looks ok, but for the EF context class filename for example... the '.' in the name is not really nice. Only using it for vs.net project files ... I'm not convinced as it's drastic (ok it was this way since the RTM but it shouldn't have been).
The only thing we have now is whether we need it to contain '.' characters because of backwards compatibility: if v2.6 projects were generating '.' in the vs.net project name, we will use the raw variant there for v3. Will look into that.
(edit) All things considering, we decided to only change it for the vs.net project name, so effectively it becomes the same as before the change: including the '.'. In v2.6 we used the rootnamespace as project name by default, in v3 we don't do that anymore. This is actually an unforeseen breaking change which we completely overlooked due to the fact we kept project name and rootnamespace in sync during testing and apparently everyone else does that too (or hasn't reported that).
So TL;DR: we'll revert the effectiveness of the change we made for vs.net project filenames, we'll use the raw name for that, and for everything else, we'll keep the change as-is (so normal filenames containing [containerName] will not have the raw name. )
This will have an influence on the presets, as the 'projectName' will be back. The effectiveness of this will be that the rootnamespace chosen is the default project name, as before the change of July 26th.