comment #5:

> find . -type f \( -exec cp -t "${IMGDIR_DST}" {} + -o -quit \)

That will never evaluate -quit because -exec ... {} + is always true, as required by POSIX. (With the '+' terminator, command failure is communicated via find's exit status instead.)

$ find --version 2>&1 | head -n 1
find (GNU findutils) 4.6.0.225-235f
$ find . -type d \( -exec sh -c 'exit 1' {} + -o -print \)
$ echo $?
1
$ find . -type d \( -exec sh -c 'exit 1' {} \; -o -print \)
.
$ echo $?
0

Sorry, that had an obvious bug, here's a fix:

find . -type f \( -exec cp -t "${IMGDIR_DST}" {} + -o -quit \)

> This is my guess because the shown use of find/xargs
> is quite excessive (one cp(1) invocation per file) and unsafe (unusual filenames
> would break the construct).

About unsafe filenames. If you talk about this:

find . -type f | xargs -IX -n1 sh -c "cp -f X $IMGDIR_DST/X || exit 255"

I understand how unsafe filenames can cause a wrond behaviour. But here(if -F/-S would be implemented):

find . -type f | xargs -F -IX -n1 cp -f X $IMGDIR_DST/X

I can't find any problem with unsafe filenames. Am i wrong?

I have to confess that I like the idea of having an option to immediately stop processing
when an invocation of the command exits with a non-Zero status.

POSIX [1] specifies the following conditions when xargs shall terminate processing:

• child exits with 255,
• child was killed by a signal, or
• when reading the 'eofstr' string if the '-E eofstr' option is given, or
• when regularly reaching EOF when reading from stdin.

Still, our xargs might implement such an option as a GNU extension.
I would recommend a long-option like --stop-on-error for such an extension.
Why did you propose '-F'?  Is there any precedence in other xargs implementations?

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html

Regarding the examples - and just to be sure:
I assume that the reproducer with 'cp' was just a simplification to demonstrate
your actual use case, right?  This is my guess because the shown use of find/xargs
is quite excessive (one cp(1) invocation per file) and unsafe (unusual filenames
would break the construct).
In such a case - when launching one process per file is required -, I'd maybe
better use the `find -exec ... '{}' \;' syntax without xargs, which could also be
used in conjunction with -quit to terminate the processing when 'cp' fails:

# Create source and destination directory.
$ mkdir src dst

# Create a regular file 'dst/f' which will cause 'cp' to fail later.
$ touch dst/f

# Create test sub-directories 'a' .. 'g', and a file 'x' in each of them.
$ cd src
$ mkdir a b c d e f g
$ touch a/x b/x c/x d/x e/x f/x g/x

# Run find to copy all files to 'dst', but stopping if 'cp' hits an error.
# Note the use of the '(' ... ')' to enforce the wanted OR-precedence for -quit
# when cp(1) fails.
$ find . -type f '(' -exec cp -fv '{}' '../dst/{}' \; -o -quit ')'
'./b/x' -> '../dst/./b/x'
cp: cannot create regular file '../dst/./b/x': No such file or directory

# Alternatively, avoid the OR-syntax with -not before -exec:
$ find . -type f -not -exec cp -fv '{}' '../dst/{}' \; -quit