The set of layers in the EXR files are expected to be the same for the entire image sequence. So from technical side of the things the patch tries to achieve something what was never designed to work. From user side it seems to cause unpredictability in terms it is unclear what image will be used to detect sockets.

The set of layers in the EXR files are expected to be the same for the entire image sequence.

Yes, but blender allows to animate the View Layer option "Use for Rendering", this means it exports multi layer exr files sequences with layers available in different range of frames. This is what the user has done in the bug report and he expects the image node to display the right sockets when changing frames and a new layer becomes available in a frame different than 1. And the image editor displays correctly the layers and its passes when changing frames. Taking into account all this, it seems the Image Node should support it.

So from technical side of the things the patch tries to achieve something what was never designed to work.

Yes I've realised this now. The patch seems to work for the bug report case with "layer 1" available in frames 1-20 and "layer 2" in frames 11-20, but I've now tried exporting EXR files with "layer 1" in 1-10 frames and "layer 2" in "11-20" and it doesn't work, ImageUser::framenr doesn't keep track correctly of the current frame and the layer RNA enum property in the ImageNode doesn't call the update function when it suddenly changes from "layer 1" to "layer 2" because enum items list has changed, even when the new enum item has a different identifier. I don't see an easy solution other than calling cmp_node_image_verify_outputs on all image nodes with image sequence option for every compositor execution and calculate current sequence frame from ImageUser offsets and current scene frame instead of ImageUser::framenr, but it's not optimal and not sure it could work.

From user side it seems to cause unpredictability in terms it is unclear what image will be used to detect sockets.

The user expects it displays the sockets of the current selected layer in the current sequence frame, all images of the layer should have the same passes for all frames in which the layer is available (at least blender doesn't allow to animate passes enable options). So it shouldn't matter which one is used but the layer must be available in that frame.

I may just abandon the patch, but I'd like to hear your final opinion about if the Image Node should support this kind of sequences. And if yes, maybe any hint on how I should do it so it could be accepted.

Thanks.

This is a good question.

Not sure what was the motivation behind allowing Use for Rendering animation. If it was done so due to design decisions, then, I'd say, all related aspects should be aware of this fact. This is something where @Dalai Felinto (dfelinto) or @Brecht Van Lommel (brecht) can give definitive answer.

How to move forward with the specific node can only be decided after the previous point has an answer.

I don't think any particular thought was given to make that property animatable, that's just the default. I can see how it's useful to save render time though, and I would still keep it animatable even if the compositor does not handle it well.

To me it seems reasonable to expect an EXR image sequence to have the same layers over time, and if that's not the case then users can import each layer as a separate image datablock with own frame range?

We should not have sockets appearing and disappearing over time in any case, you can't reliably build a node graph like that.