I don't know Brett....even if this wasn't a question about rewriting large parts of the texture editor and if it would work in all the plug-ins....I don't see myself clicking any less in this system.
This is just my opinion but do I really reuse the same map in tens of materials in the same scene? Yes, but perhaps 1 or 2, and in those cases it's almost certain I won't use the same settings like contrast, invert etc. What I find myself often doing is changing the tiling in the same material to make sure all the DIFFERENT maps match in tiling value. I don't see in this instancing texture system how that would be solved. Because often, I do use the same map in different materials, but depending on the type of material I may use different tiling values for it, so again, I need a way to quickly change the tiling globally in the SAME material.
I can see how texture instancing could be useful, although for me personally I don't know by how much. What are some concrete examples?
It depends on the case. What you are talking about is more of a case of parameter wiring than actual texture instancing, which is a different thing and also hugely useful. I often use both, and often in the same material. I agree that the image properties (as they are called in MXED, brightness, contrast etc) are often unique in to different slots, but the projection parameters would be instanced. That is a common case - where you might use variations on a black and white map in roughness, and anisotropy (just as example) and use them several times in one material (say 3 BSDF layers) and again in two different but similar materials. It is not hard to have a case where one map is used 10 different ways. In such a case projection parameter instancing is the thing, but without a separate "container" for the image properties it is more a question of parameter wiring (linking the tile values etc) than a true instance.
However, it's also possible to need to instance the image properties. Think of a multi-layer material where the same weight map is used to blend several layers, and even across several variations of the material. In that case the image properties would be usefully instanced too. In such case you can use a "true" instance of the whole texture as it is currently defined in Maxwell, or you would need a way to instance the "container" I was speculating about.
While I understand your point that global tiling can be useful, in my own material work that would be a very rare case. It is far more common for me to use several different maps in a single material and each one can have wildly different tiling values depending on the actual maps. As Polyxo pointed out - that may not apply to custom painted maps (which should not tile at all), but then neither version of parameter instancing is relevant
Being able to instance at several levels (bitmap itself, projection, image properties, BSDF, material layer) allows for a far more fully developed material workflow. Not everyone would need it, but it would be a godsend to those of us that do. As a case in point here is a carpaint type material of mine - I'm showing the node view just because it provides a clearer snapshot of the many levels of interconnectivity:
This is a complex one, but the legwork up front in building it has made for an extremely verstatile material for me. That level is not *super* commonly needed, but it's a case that shows instancing/wiring at pretty much all levels, and at slightly less complex levels it is far from rare.
Here's a more common one - this is for a slightly worn chrome:
The parameters in yellow at the far left would be what I call parameter wiring: tiling values for the actual projection. The next two levels are not really reproducible in Maxwell, but essentially I am using 12 bitmaps blended into a Composite map (which is what I would call a ``container`` shader). That Composite just allows me to blend the bitmaps much like a Photoshop document with all the bitmaps in various combinations of overlay, multiply mode etc. It shows you the kind of functionality that I think it very useful when you can separate the instancing of projection versus image properties.
Further over you have the equivalent of instancing that final image map (the result of the composite) into a few texture slots of a material (that would correspond to a BSDF layer and it`s slots). In the top one it`s actually nested in yet another node that lets me change brightness/contrast.
The final product in this example is a blend material, would correspond to a normal Maxwell material, where each sub-material is like a Layer in MXED.
It would not be hard to think of a case where most of this entire node diagram could be usefully instanced to yet another chrome - say one that had some typography in it, or that was supposed to be dirty or more shiny, or more worn, etc. etc. In that case being able to instance MXED material layers between different MXM's would be necessary.