What Should Be Added or Changed?

While the existing material model system works, it is a bit cumbersome for pack creators, and the JSON is a bit difficult for some to understand. It should be reworked, but without breaking existing files.

One solution is to add a simplified model type. It would accept a named texture set (stone, metal, etc) and a primary color. The model could then determine the specific textures it needs based on the material. It could also contain an optional override list to customize specific cases.

The material data files should also contain model information, like they used to. This data would be sent to the client as a default model, which could then be overridden with a resource pack, leaving existing packs compatible with newer versions.

For the texture sets, the existing ones (PartTextureSets) can be used, but new ones with more specific names should be added. For example: wood, stone, metal, gem, etc. Most metals and gems already use the same set, but the descriptive names are more helpful than "high contrast with highlight".

Why Should This Be Done?

Easier creation of materials thru data packs. Eliminates required resource packs.

JSON Example

An example or rough draft of what the simplified models could look like.

{
    "texture_set": "metal",
    "colors": {
        "primary": "#e1e100"
    },
    "overrides": []
}

Could it be possible to let modpack/mod-makers add their own texture-sets for more variability and control over the look of their materials?
For example, a texture_set could be defined by a folder with several json models in it for the different textures that are required (armor models, item models for tools and fragments, anything else you might add in the future). This could be a dedicated folder in the resource pack (?)
Then in the data-pack, this folder can be referred to in a json defining the texture-set.
Then whenever you are reading json's depicting the texture-sets of materials, unknown names would have to be defined in a loaded datapack (doesn't have to be the same datapack) and set to default if it isn't found.

+edit: for consistency's sake, the built-in texture-sets can also be defined in a datapack

I think this would be a nice addition for modpacks where you don't want to make a custom texture for every material, but still want to add some distinction between them (e.g. you added 30 different metals, would be boring if they all look the same).

Good idea. Although in that case it would probably be best to treat the "texture set" as a model too. Then specific materials could select one as a parent model, similar to how vanilla block and item models work. I guess the question then is how best to define those on the server side, but I'm sure I can work that out. Maybe just some dummy materials that exist to define the model.