yep... this process pretty much sucks now.

ideally we'd be able to provide an alternative AtlasAsset to load from rather than just the one specified in the AtlasAssets array of the SkeletonDataAsset. No code exists in the runtimes to let you do that though. Ultimately what I think will happen is a delegate function will need to be created that says "GetAtlasAssets()" and you can override that when you want to when initializing a new skeleton.

Can't you just use Renderer.GetPropertyBlock and Renderer.SetPropertyBlock on a per skeleton basis. I think it is meant to support not breaking dynamic batching but I can't be sure, it should work for different float, color or vector properties. If you set that though then you could modify the material properties without duplicate instances. You could then just modify propertyblock per skeleton with a script, or write some .txt, .json or .whatever file that you parse that contains info for each skeleton, and then instantiate the skeletons and change their property blocks based on that info, either within the Unity editor or at runtime... At least that way you would only have to maintain a text file or excel file (export to csv) for 150 different combinations.
Just throwing some ideas out there, hope it helps

My skeletonRenderer is heavily modified so I'm not so sure about line numbers...

But if you are referring to the place where the sharedMaterials are overwritten, then it is possible.
If you had a shader property "someColor" for example, then to change it for lots of different skeletons you could just do the following; (this is bad though, don't actually do it like this, cache propertyBlocks, don't create a new one each frame)

// Set materials.
        if (submeshMaterials.Count == sharedMaterials.Length)
            submeshMaterials.CopyTo(sharedMaterials);
        else
            sharedMaterials = submeshMaterials.ToArray();
        GetComponent<Renderer>().sharedMaterials = sharedMaterials;

// New stuff 

---


    MaterialPropertyBlock block = new MaterialPropertyBlock();
    GetComponent<Renderer>().GetPropertyBlock(block);
    block.SetColor("_someColor", someColor);
    GetComponent<Renderer>().SetPropertyBlock(block);

with someColor being, for example, a public serialized property I just added to skeletonRenderer to demonstrate. You can see two crap test skeletons below that have the same material, but different colors as specified per my new skeletonRenderer property someColor...

Anyway, it's perhaps a moot point since they didn't seem to batch on my end. Will keep digging for a bettter solution, but I think it should be totally doable without multiple material instances.

Excellent! I imagine I just did something stupid on my end. You should be able to do alot with custom properties moving forward. Have fun with it!