I'm pretty well-versed in *nix administration. I'm no developer or hardcore coder, but I can get my way around code well enough to be dangerous.

I wish there was a filetype that was actually two (or more) files chained together. From the user perspective, it is a single file; however, once saved, it is actually multiple files. There would need to be markers in the source file to indicate where to split, but that's not hard. This would solve things like above-the-fold CSS problems by allowing all CSS to be managed in a single place while in reality having it split up dynamically for purposes of efficiency.

Conversely, I wish there were a way to dynamically "embed/link" config files. Say you have multiple htaccess files, but they all need to have the same mod_deflate directives. There could be a single mod_deflate file that is referenced by all htaccess files - edit the "master file," and all the others inherit those changes.

I can think of ways to build these structures by creating static versions of the desired files whenever the source files are changed, but that gets messy - nothing prevents the static copies from being accidentally changed. There is no solid parent/child link that would persist after file save to prevent that modification.

I suppose I'm just rambling, but does anything exist that I'm just not aware of?

Yes.

Webmin interfaces for some applications have one settings screen. When you sumit the settings they are written out to the config files where they are needed, one file or many.

May config systems that were once a single config file now include an "include" macro that can load up settings from another file, or all the files in a special folder. Applications are routinely written to include directory parse functionality.

Example: not long ago /etc/profile was critical. It still is, but check out /etc/profile.d as well.

Man pages do a good job of letting you know if your application handles a setting folder instead of, or in addition to, a settings file.

While that is indeed true, there is an application layer or management system that is required for that to work (and they're all different). Instead, how nice would it be if there were a way to do this at the system level? The second case would be easier to accomplish and could be an extension of ln and tar in a way (by way of analogy, really). For instance:
The -l option would be "link," and it would instruct the system to dynamically chain the files together when read. Since tar is nothing more than a bitstream of files clumped together with a header table specifying where each file starts and stops, code that is similar to that could do the actual work. When running ls -l, the linked child files would be shown.

The first case is quite a bit harder to handle from the system level. To use my previous analogy in reverse, imagine editing a tar file using vi to edit the files that are contained. One would have to know what file is currently be edited on the current line and make sure to update the header tables at the top with where each file now starts and stops in the stream. I can envision how that could be accomplished, but it's not as easy as the opposite direction.

I'm not posting so as to suggest that these things need to be implemented. Rather, I'm just musing. I sure wouldn't complain if they WERE implemented - there are definitely problems that could be solved by such structures!