I got the question the other day on why we went to create a new HTML/CSS framework for a new design that we were deploying, and why that framework had to have a different name than the design that triggered its creation.
My (shortened) answer had two parts:
1) Normally you want to work with your existing infrastructure, i.e. maintain the HTML/CSS framework you’re already using. However, if you’re dealing with major content and thus structural changes, it can well be justified (and more economic) to create a new framework. (We had another good reason but it’s not related to the point I’m trying to make.)
2) CSS, and thus HTML/CSS frameworks, are design-agnostic. You do not want to name a framework (or simply a style sheet) the same way you name your design because it should be your sincere goal to use the same framework for the next design iteration (and the next, and so on), all of which may have different names again. (Note that you could also end up having two or more frameworks for the same design—I’ve had this case, also in a complex environment—which could obviously not have the same name. As frameworks are design-agnostic, this is fine, though maintaining two or more frameworks is pure luxury.)