You are definitely right that, in general, a user should be permitted to rename and move files as they see fit. If you can do that, do it. That way they can easily make backups, go back to an older version of a file, or switch between documents or document sets.
However, that is not always feasible for every system. Can you elaborate on your app and what it does? Is it more a situation like an Office suite, where you can create a Word Processing document, or a Spreadsheet document, or is it more a situation like a web page where you have an HTML file that ties together a bunch of related resources (images, style sheet files, JavaScript files)?
If it's the former, you should really use different file name type suffixes. That way your app can easily tell apart what stuff is in it, and provide a nice icon that conveys the same information to the user. However, changing the suffix sounds like an odd idea. Is .Data the old extension and it will change just once when they upgrade to a new file format? Files that randomly change extensions based on changes are (generally) not a good idea. Users expect their file names to stay the same. Otherwise e.g. a user's scripts to backup a certain file would constantly break, so try to avoid that.
If the format really only changes for internal reasons to your application, make that part of the file format, e.g. by starting it with a magic character sequence, but leave the name and extension untouched.
If your setup is more like a web page (but not really a web page), one approach you can use is to wrap several files in one. On some platforms, this happens automatically if you put them in a folder that has a file name suffix (e.g. on Mac OS X). That folder then shows up as a single file (well, you also need to associate that suffix with your application, but that's how it generally works). That way, you can have several files internally, but to the user it is a single document.
Other platforms achieve similar things by using ZIP files for their file format. They give them their own, custom suffix, but write several files into that one achive. To the user it's one file, but your application can read/write, control the names of the files inside the archive and even build a folder hierarchy.
Now in the case of an actual web site, it's more difficult: Web site authors these days are used to being able to edit images in Photoshop and the actual HTML and CSS in their favorite text editor. So unless the purpose of your application is to replace all these tools (e.g. because it is a web site builder for non-technical people), you'll have to leave the files separate.
If you're dealing with such a case, your best bet might be to just group those files in a folder, and let the user browse all the sub-files in that folder from your application. Don't worry about the surrounding folder, and just expect the user to not modify the relative positions of each file. If you need to store additional data, put a special file in that folder with that extra information. The question, of course, would be what to name that file. If you can accept an arbitrary name, that's good. If you need e.g. one file per HTML file in the folder, use the same name as the HTML file but a different suffix. But be aware that all of this makes usage very technical and nerdy and increases the potential for a user damaging the files.
While your system may have training, it's always simpler to avoid usability issues in the software design, than to have to continuously train (and remind!) users after the fact. Of course, if your company makes its money off its training contracts, that might undermine your business model, but is that really how you want your users to remember your app, as complicated? Or would you rather train them in advanced things and have them happy?
Now, all the above describes the ideal case. Sometimes, your application is simply so complex that you expect people to be familiar with file naming conventions and folder hierarchies. E.g. the Apache server is an example where there is a good reason for (most of) the complexity. If your system can't be made to fit into one of the simpler file system schemes outlined above, try to at least limit the number of files your users are exposed to.
E.g. on MacOS, the user files for a server are ~/Sites for the user-specific files (rooted at example.com/~username) where any user can mess around all they like and easily host files. There's a /System/Library/WebServer/Documents/ folder for files at the root level (harder to find, but usually under the admin's control anyway), and there are the standard Apache files for CGIs, configuration etc. that are not supposed to be user-serviceable, which are in /etc (a folder hidden in the UI by default), and usually only accessed using the GUI for configuring the server, never directly, unless you're really nerdy.
The only special filenames in the user folders are ".htaccess" (hidden, only for nerds) and "index.html", which, if you know to create it, is the default file shown when you don't give a file name. So not really important to know to view a file from the outside. Everything else keys off file name suffixes.
So, in summary: If you can let the user give their own names, do it. It's their computer, their file system. If the file system is not supposed to be user-serviceable, make sure you hide stuff away in folders, invisible files, folder packages or ZIP archives.
