I'm not sure whether I understand why exactly the OP is speaking of overkill. It seems me that using a package name within the resource name is making the problem. If so, the following description may help; if not … feel free to ignore my post ;)
When the system starts up, it scans a specific directory (the "overlay" directory) for files, and assumes each file to contain a single resource. It stores the names of the files as names of resources in an internal table of content. I'm using hashes for resource names at the runtime level, but the file-path names relative to the directory would work as well. The system further scans another directory (the "package" directory) for files, and each file determined to have the correct format is opened and its stored table of content is integrated with the one already in RAM. During this, if a resource name collides with one already in the internal TOC, it is ignored and the internal entry left as is; additionally, if the already contained entry refers to a package as source, a conflict is logged.
The table of content now has entries for each single resource. The resources' names managed therein are not tagged by a package name or whether they origin from the overlay directory. But these additional informations are stored along the resource name in the entries, of course.
A file offset and length is stored in the TOC for accessing a resource inside the package file. Now, the file offset and length does not necessarily address a single resource but may address a sequence of resources. This is called a load unit, because all addressed bytes are loaded (and later unloaded) at once. Nevertheless, the entries in the TOC are still names of individual resources. So requesting any resource of a load unit causes all resources in that load unit to be loaded. A "bill of materials", as may be stored along a resource to declare dependencies, ever lists each single resource.
Of course, before the loader is requested to load a resource load unit, the cache is interrogated whether a resource is already loaded.
With a concept like the one above, resources are requested by name and regardless of their storage location, and regardless of whether they are bundled in a load unit or stored in their own load unit. It allows for hot-swapping during development and for installing updates without the need to send an entire package file. All dependencies are still explicit on a resource by resource basis. If for some reason the toolchain decides to store a particular resource now in another load unit, the bills of material need no update.
Edited by haegarr, 30 May 2014 - 02:33 AM.