I know that seems like a dumb thread title... (of course it's going to error on a bad path, it has a bad path!)... As it is now, this error stops networks from cooking. Am I crazy to want the rest of the cook to proceed anyway even if, at render time, materials aren't resolved properly?

I'm thinking of scenarios where, for whatever reason, the source materials that are being assigned may not be present on the composed stage, but the node is still trying to assign them. In my view that shouldn't be grounds for halting the cook, but maybe it is?

Not a dumb question at all. Most LOP nodes (such as Transform) if you specify a bad path, or a path pattern that returns no results, the node will still cook. It might flag a warning if you give an explicit path that can't be found, or that points to an instance proxy or other non-editable prim, but it will always finish cooking successfully. Assign Material is a little unusual in this regard. But you'll notice it only errors if the material doesn't exist. If the geometry path is invalid it finishes cooking with a warning. So why is the material path different?

Our thinking was that with this node, there was a very high probability that a missing material would be accidental and that the user would want to be made aware of the issue. Warnings are almost universally ignored in my experience. Only errors really get your attention.

The other possible approach here would be to have a toggle parm that controls whether a missing material should be treated as an error or a warning... It's a bit of a hack, but lets us preserve backward compatibility, let the user know in an obvious way when there is an issue, but lets you get around the issue if you decide that it's okay for the material to be missing (in which case we can just flag it as a warning)...

Just speaking for me personally, I think a warning rather than an error would be appropriate. I understand your point, I just think throwing an error imposes a pretty rough consequence.

In our particular production scenarios, it's pretty trivial to assign a fallback 'debug' material to some root prim, with opinion strength left at Default, to tag geometry that is "missing lookdev". Only geo that has no resolved material or existing opinion/relationship defined will pick up this material. For us, that's a friendlier indicator of 'bad material' as it doesn't break any LOP networks and still lets us get renders out (at which point we clearly observe the problem, but compositing still has content to work with). Would love an option that prevents a bad material path from erroring the cook. Maybe there is a non-hacky way to do this?