Must be kinda the same thing than #364 (better to get a read on there first as I use the same pack/parts to describe this issue)
I was trying to get a workaround. My idea was to get rid of the main texture.properties by making different models with the main texture override unique to them.
Then the cape part would match the modelsuffix instead of the texture to get his texture applicate. This is actually working with this configuration:
Villager.properties

models.2=   2 3 4 5
weights.2=  1 1 1 1

models.3=   2 3 4 5
weights.3=  1 1 1 1
nbt.3.SleepingX=exists:true

Cape.properties

modelSuffix.1=5
skins.1=1
modelSuffix.2=2
skins.2=2
modelSuffix.3=3
skins.3=3
modelSuffix.4=4
skins.4=4

Now, if I set the cape.properties this way with only model 5 of villager in the villager.propertie then it also does work as intended

modelSuffix.2=5
skins.2= 1 2 3 4
weights.2=  1 1 1 1

However, If I set models 2 & 5 for the villagers, and the following for the cape, then the cape only ever get only one color per model.

modelSuffix.2=5
skins.2=  1 4
weights.2=  1 1 

modelSuffix.3=2
skins.3= 2 3
weights.3=  1 1 

And when the cape.propertie try to set the four colors at random for both models, it only apply to of them per model

modelSuffix.2=5
skins.2=  1 2 3 4

modelSuffix.3=2
skins.3= 1 2 3 4

Here is the pack for testing models villagers.zip

On a side note related to #363 using model with suffix different from 1 seems to make it that NO layers is displayed.
Tested on 1.21.1, with only EMF/ETF and they where from the discord latest dev builds

this is because the randomisations are lining up perfectly because you are using the exact same number of models and weight vaues for both. change the weights slightly and they will no longer sync up

It does work indeed.
I don't know why in my mind the variation would be model based since it's uuid.
I'll close this issue then.
I bet making variation of overrided parts model based would break optifine compat and probably make more harm than good for a pretty niche use anyway.