A design problem: how to represent resource id's

[I'm cross-posting to comp.lang.c++ since any solution is constrained by
that language, i.e. this is much about how to use that language]

<what to design a C++ solution for>
A Windows API /resource/ is data embedded in the executable, accessed
via API functions. A resource is completely identified by the quadruple
(id, type, language, file), where (1) id is what, for want of a better
name, I'll call a /kludgeon/, (2) type is also a kludgeon, (3) language
is a small integer identifying a concrete national language or one of a
set of pseudo-languages such as the Windows installation's language or
the language implied by the locale associated with the execution thread,
  or it is an empty specification, resulting in the API level's
unspecified best match with the thread locale's implied language, and
(4) file is the executable file or DLL the resource resides in.

A kludgeon, used for id and type, can be a 16-bit integer or a general
identifier represented as a string. Vis-a-vis API functions it must be
specified as (1a) a pointer to a general identifier string, or (1b) a
pointer to a string of the form "#1234" for integer id 1234, or (1c) a
pseudo-pointer with all bits zero except the 16 least significant bits,
which then specify an integer kludgeon. An API function kludgeon
argument is typewise just a pointer to char or wchar_t (call that TChar
for simplicity, i.e., argument type TChar const*), and accepts any of
the forms (1a), (1b) and (1c) -- the latter being most efficient.

For naming kludgeons, if that cannot be avoided, one relevant fact is
that the same representation convention is used for Windows "atoms", but
atoms are dynamically allocated things, whereas kludgeons are not.

The language identification is constrained by the set of languages
supported by Windows, i.e., generalizing it can be problematic.

The file specification can be (3a) some identification of a file system
file, e.g. a path (there are also other ways to identify a file, but
probably irrelevant), or (3b) a 32-bit module identifier, called a
"module handle", where a /module/ is the loaded image of an executable
or DLL, such as the loaded image of the currently executing program.

Ordinarily one wants the file to default to the currently executing
program (a module handle is very easily obtained from the API level),
and the language specification to default to the empty specification.
</what to design a C++ solution for>

The main requirements are (1) correctness and safety, (2) clarity, and
(3) efficiency, since this is for my third installment about Windows
programming (for the two first installments, see <url:
http://groups.google.com/group/comp.os.ms-windows.programmer.win32/browse_thread/thread/fc61acc7316d9257/892100ca99fe8200>
or, as tinyurl, <url: http://tinyurl.com/pgzlq>). Functionality,
especially general file specification functionality, can suffer.

It's no big deal to design a "working" solution; in fact, the API level
itself is a "working" solution, so for that, nothing more is needed.

What I'm up against is a conflict between the three main requirements;
it's difficult to satisfy all three.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?