Rigid file name schemes and interoperability

Some programs require that the name of the passed file has a specific scheme. For example, just now I want to start programX and it won't work, if config file has no proper extension.

There are better or worse reasons to do that. But the cons include, at a minimum, reduced interoperability.

For example, "process substitution" is a convenient way to pass file-like objects constructed on the fly from the output of an arbitrary command. In Bash, we should be able to run

$ programX --config <( cmd )

where cmd generates config contents.

But because we have no control over the name under which this file-like object is accessible, we can't force it to have extension in its name.

Sure, we can always write even more shell to circumvent that. And sure, Zsh has =() variant, which writes to an actual file which name we can control (or so I've read).

But that's the point. Interop suffered here.