TYPO3.Flow

Mh, not so sure.. The current behavior is what I would expect:

1\TYPO3\Flow\Utility\Arrays::arrayMergeRecursiveOverrule(array(0 => 'foo', 1 => 'bar'), array(0 => 'overridden', 2 => 'baz'));
2// array(0 => 'overridden', 1 => 'bar', 2 => 'baz'

The actual problem is probably, that we use non-associative arrays for the ignoredTags setting (another problem of this that you can't unset a previously defined tag).
In user code, this could easily worked around by using array_flip I guess

yes, the current behavior is even documented behavior:

In case of identical keys, ie. keeping the values of the second.

Ok, well, maybe the method "arrayMergeRecursiveOverrule" is not the right place for this, since also/even the naming of the method implies that numeric keys are overridden mercilessly.

OK, so the problem rather lies in how Settings are merged together.. maybe a distinction here is adequate.

This is really a PHP problem since "numeric" and "Associative" arrays are technically the same; where in other languages like JavaScript (and the Yaml representation), a numeric array is an array [] and an associative array is an object/hash {}...

For Settings, I really would expect arrays [] being interleaved, while hashes {} of course are merged and overruled on same index.

See my last comment @ https://review.typo3.org/#/c/13847/ additionally, please.

The general problem stays - we cannot currently append tags to the ignoreTags configuration, which majorly limits configuration for otherwise broken 3rd party libraries (tcpdf, gedmo, ..).

The real problem, as Bastian noticed, is a syntax problem with the ignoreTags setting. Switching from array to dictionary would work, but make the declaration of tags ugly and cumbersome:

TYPO3:
  Flow:
    reflection:
      ignoredTags: {'api':'', 'package':'', 'subpackage':'', 'license':'', 'copyright':'', 'author':'', 'const':'', 'see':'', 'todo':'', 'scope':'', 'fixme':'', 'test':'', 'expectedException':'', 'depends':'', 'dataProvider':'', 'group':'', 'codeCoverageIgnore':''}

Extending YAML doesn't make sense, as it is a defined standard, so we're left with:
1) living with the ugly syntax
2) change the way we deal with numerically indexed arrays in configuration loading, meaning changing arrayMergeRecursiveOverrule or replacing it there

I'd go for number two and add a new arrayMergeRecursive function that only overwrites associative arrays.
Determining associativity with SchemaValidator->isNumericallyIndexedArray will not work, because it would also regard YAML dictionaries like

{0: '0', 1: '1'}

A function to determine associative arrays could look like this:

    /**
     * Determine whether the given php array is an associative array
     *
     * @param array $phpArray
     * @return boolean
     */
    protected function isAssociativeArray(array $phpArray) {
        $last = -1;
        foreach (array_keys($phpArray) as $key) {
            if (!is_integer($key) || $key != $last + 1) {
                return TRUE;
            }
            $last = $key;
        }

        return FALSE;
    }

So, only strictly monotonic integer indexed arrays with keys starting from 0 are regarded non-associative. The only loophole would be arrays that are declared like this:

$array = array( 0 => '0', 1 => '1' );

This would mean, all array type configuration settings will not overwrite, while all dictionary type settings will overwrite.

Hum, didn't know that PHP converts all numeric strings in array keys to their integer equivalent... i.e. there's no difference between array('a','b') and array('0' => 'a', '1' => 'b'). Bad bad PHP...
Well, that kind of messes everything up, because then also YAML dictionaries that are indexed 0...n will be regarded non-associative. Still better than not being able to append array options, but that behaviour must then be documented correctly.

Issue can be closed, the solution will be to change the configuration syntax to use dictionaries for configurations where merging without overwriting is wanted/needed.