To me, index_0 style arguments are valid only on child definitions, and should be resolved by ResolveDefinitionTemplatesPass, thus before ResolveNamedArgumentsPass.
Thus I'm not sure this PR applies, or could you please provide more details to "prove" the bug?

Oh sorry.. understand the confusion.. this is about plain & simply;

Foo:
  class: Foo
  arguments: { index_0: first, index_1: 2nd, index_2: third }

:))

edit: so used to new syntax.. but updated the issue.

in general; this pass looks very aggressive by default. Shouldnt it only deal with expected $something args only and skip anything other.

about the strategy, named args overwrite indexed ones and we should probably extraxt the resolved index from index_N for this PR as right now im assuming correct order :) imo. this could be as simply as https://github.com/symfony/symfony/pull/22204/files#diff-ba90e85087b3a48467101a7ee7d21691R53... only change something very specific and dont reorder anything. Both could use a AbstractRecursiveArgumentsPass pass actually..

extraxt the resolved index from index_N for this PR as right now im assuming correct order

AFAIK, this has never been the case. Ordering based on index_0 style as in your example would be a BC break. To me, the exception is correct: you need to fix the definition. It can even be misleading, since the index_N order does not apply. Such indexes are only valid in child definitions to me.

Currently, this PR and report is bogus, please provide more details if you think otherwise :)

It's really working in 3.2 :)

services:
    x:
      class: AppBundle\Foo
      arguments: { index_0: first, index_1: 2nd, index_2: third }

Foo {#243 ▼
  +a: "first"
  +b: "2nd"
  +c: "third"
}

edit: the order is preserved indeed

That's why it's documented as a bc break yes, one we chose to do, because such configs are bogus to begin with :)

See #22185

Ok my bad. I just did not expected it (should have) related to index_N notation as well.. considering it's special meaning. 👍 Sorry for wasting your time :(

No pb! A big thank for playing with master and reporting issues, even if this one is not valid :)