Merging capabilities seems broken?

Imagine trying to process the following:

{
    "alwaysMatch": {"browserName": "fake"},
    "firstMatch": [
        {"browserName": "real"},
        {}
    ]
}

Per step 7.1 of process capabilities:

Let merged be the result of trying to merge capabilities with required capabilities and first match capabilities as arguments.

"Trying" returns the error if it fails, so I think the merged capabilities ends up with:

[
    [abstract error],
    {
        "browserName": "real"
    },
]

This seems wrong, given we then assume the argument passed to "match capabilities" is a JSON object.

If we instead use the same JSON serialization of an error as send an error — though we don't define this outside of sending an error so this is definitely not what the spec currently says — then the merged capabilities would be:

[
    {
        "error": "invalid argument",
        "message": "[implementation defined]",
        "stacktrace": "[implementation defined]"
    },
    {
        "browserName": "real"
    },
]

This also doesn't seem particularly helpful.

From the look of our current tests in /webdriver/tests/classic/new_session/merge.py, we seem to expect the following to return to the client "invalid argument":

{
    "alwaysMatch": {
        "acceptInsecureCerts": True
    },
    "firstMatch": [
        {},
        {"acceptInsecureCerts": True}
    ]
}

Thus it's not that we're "trying to merge capabilities", it's that we need to process that error by then returning error.

Start with step 7.1, “process capabilities,” and compare its “trying to merge capabilities” wording with the “match capabilities” input assumptions. Review webdriver/tests/classic/new_session/merge.py, especially the invalid-argument cases. Done means the specification defines how a merge error is handled and the related tests reflect that behavior.