Separate bone weight Vertex Groups from other Vertex Groups

I've run into a nasty issue while painting bone weights on a character when I'm already using Vertex Groups to mask unrelated modifiers. The workflow of normalizing bone weights using "Normalize All" and "Auto Normalize" doesn't gracefully support meshes that use Vertex Groups for more than just bone weights.

Request:

• Provide some way to separate bone weight Vertex Groups from all other Vertex Groups, so that "Normalize All" and "Auto Normalize" features only consider the bone weights.
• This could be a generic grouping system within the Vertex Group dropdown, or bone weights could automatically be segregated from other vertex groups.

The specific issue I'm having, that this feature would resolve:

• My mesh has a vertex group called "outline" acting as a mask for a toon inverted-hull outline effect using the Solidify modifier. It contains hand-painted weights for how thick the outline is at each vert.
• I parent my mesh to a skeleton, and now I have 100 or so vertex groups for the bone weights.
• As soon as I normalize my bone weights, it normalizes the outline group along with the bone weights, obviously not what I want.
• If I choose to lock the outline group, I eventually run into issues with Auto Normalize when painting in Weight Painting mode. (Auto Normalize seems to fall over when there's one locked vertex group with near 1.0 weights everywhere, in addition to all the other groups' weights adding up to 1.0. Wacky behavior occurs where strokes that should add weight remove weight sometimes.)

My current workaround (which I feel is unpractical):

• I make a duplicate of my mesh that is not skinned to the skeleton, with my outline vertex group.
• The original mesh has an outline vertex group, but it's 0'd out and locked.
• The original mesh has a Data Transfer modifier that transfers the duplicate mesh's outline group data over.

Note that this is a simplified example. In reality, this is multiple meshes with multiple unique vertex groups containing various flavors of data that should never be normalized against each other. The workaround I have is a significant headache and prone to human error.