Hugo Kornelis (2/11/2011)
The reason the resource database was introduced was to make applying service packs easier. Instead of dropping and creating system objects in the master database, the SP executable simply replaces the MDF file for the resource database. This was described in one of the links mentioned in this topic.
So I guess that having to search for the current location of the resource database felt like too much work for too little gain. One simple, immutable, hardcoded location is the easiest possibility.
Or they had bad experiences with customers placing the resource DB on a bad spot and expecting MS to fix the mess, and wanted to avoid those problems going forward.
I appreciate the speculation; it sounds like a reasonable explanation for the scenario...
Would you care to voice an opinion on whether this kind of heavy-handedness is a good idea?
I answered "yes" (movable) because it was unthinkable that there should be a requirement for files to live in any particular location. Microsoft forced the registry on us and now they can't be bothered to use it to find a file location? That's the kind of laziness I'd force a coworker to rewrite/fix, why are we collectively ok with it from Microsoft?