I'm slightly confused as to what case this is covering? Is it explicitly filtering out TOML table headings? If so, why isn't strip_prefix covering this case?

The point is to exclude any JSON path where a bracket notation is used to access an item below an array. Such a path is currently considered as ill-formed (the path expression is left unchanged), by contrast with paths leading to an unknown value (the path expression being then substituted for the empty string). See #2918 (comment).

Why is accessing an array value considered invalid? Because array indexes positions are non-deterministic? Or to avoid out-of-bound index risks? If it was the latter, I'd have used the same logic for that as unknown path in an existing root: returning empty.

Why is accessing an array value considered invalid? Because array indexes positions are non-deterministic? Or to avoid out-of-bound index risks? If it was the latter, I'd have used the same logic for that as unknown path in an existing root: returning empty.

Not yet implemented would be a better term. I fully agree that this can be useful.

Why is accessing an array value considered invalid? Because array indexes positions are non-deterministic? Or to avoid out-of-bound index risks? If it was the latter, I'd have used the same logic for that as unknown path in an existing root: returning empty.

Jus wondering if we should add some additional restrictions to the variable substitution in script and operation names, limiting the substitution to primitive types only (Strings, numbers etc) and explicitly prevent complex values like arrays and objects as that's most likely an error when used in a script/operation name? It would be better fail during the validation phase itself rather than during execution.

Yeah, why not.

Though this shouldn't prevent passing complex objects as arguments to the script right?

For example:

[executing]
script = "/usr/bin/do_something ${.payload}"

Sure. I think @albinsuresh is speaking only about operation names.