First instance output:
write exr tmp file, 960x540, /tmp/bugtest.blend_Scene_RenderLayer.exr
read exr tmp file: /tmp/bugtest.blend_Scene_RenderLayer.exr
OpenEXR-readPixels: ERROR: Error reading pixel data from image file "/tmp/bugtest.blend_Scene_RenderLayer.exr". Unexpected tile x coordinate.

Second instance output:
write exr tmp file, 960x540, /tmp/bugtest.blend_Scene_RenderLayer.exr
read exr tmp file: /tmp/bugtest.blend_Scene_RenderLayer.exr

This is an old design problem, the temp file thing has basically two uses which gives issues in this case. It's used as temporary storage during renders, but it's also used as a kind of cache so that when you restart Blender or reopen a file, the last render can be loaded and you can do compositing without having to re-render.

Thanks for having a look at this Brecht. The TMP file just needs a unique name for each instance instead of just based on the filename alone.

Is there any type of id or data that is unique to the instance that could be appended to the filename? Or perhaps just a timestamp (down to milliseconds), as I never launch both instances exactly at the same time.

It's easy to add the process ID, but this would give a ton of files and disk space usage in the /tmp directory as they aren't actually removed after rendering, especially if you are using a background render with a Blender process for each frame. And it doesn't work with file reloading for compositing because the process ID would be different, so that needs to be solved too.

The design needs to be thought out more rather than just using unique filenames.

So is this an issue for background command-line rendering too?

You can use separate temp folder for command-line rendering.

This issue has been discussed already (see T28314), And since it's a design limitation rather than the bug archiving this report.

Thanks for the report anyway.

◀ Merged tasks: T28314.