You don't, and Joshua Delahunty (the one who initiated this process) has a proposed solution to the problem, but I didn't include his solution in my proposal. His solution is a separate gray-scale "glossmap" that determines the shininess of each pixel in the texture. Note also that while the textures will likely use RGB values from LDConfig.ldr, they will not be using LDraw color codes directly.
I removed references to gloss maps in the proposal for a few reasons. First of all, I haven't implemented support for it, and without a proof of concept implementation, I'm leery of proposing it for ratification. Secondly, Joshua's proposed syntax wouldn't have worked well with texture filenames that include spaces. It's legitimate to simply disallow spaces in texture filenames, but now that we allow spaces in model filenames (although not part filenames), I don't think that's the right approach. While it's true that the main motivation for the textures was parts, support for them could be added to modelers to allow arbitrary stickers.
I removed references to gloss maps in the proposal for a few reasons. First of all, I haven't implemented support for it, and without a proof of concept implementation, I'm leery of proposing it for ratification. Secondly, Joshua's proposed syntax wouldn't have worked well with texture filenames that include spaces. It's legitimate to simply disallow spaces in texture filenames, but now that we allow spaces in model filenames (although not part filenames), I don't think that's the right approach. While it's true that the main motivation for the textures was parts, support for them could be added to modelers to allow arbitrary stickers.