As I discovered on bug 1525126 comment 43 some of the capabilities Marionette gets from geckodriver are always passed back with their original value, which means that capabilities like browserName, which get set by Marionette, are lost.

For example for capability matching the browser name is set to firefox, but Thunderbird is getting started by specifying its binary path. While Marionette sets thunderbird as browserName, it won't be included in the returned capabilities. Instead firefox is still listed as browser name.

Here the reply from Andreas:

(In reply to Andreas Tolfsen 「:ato」 from bug 1525126 comment #47)

I think perhaps there’s an argument that Marionette should only
care for the specific capabilities it needs for setting various
options, and ignore any additional stuff passed on by geckodriver.
This would let the original value for browserName from
Services.appinfo.name to be passed back:
https://searchfox.org/mozilla-central/rev/588814f2edddf0e132d77d326ddae50911e8bad1/testing/marionette/capabilities.js#438
writing everything back on matched

IMO this is really something we should do. Compared to other browser vendors we have different applications, and as such should correctly validate various capabilities. There are also a couple of other capabilities which are affected too.

I should also mention that the way Capabilities._match() is
written, if a client provides an enormous binary blob on a key not
recognised as configuration by Marionette, this arbitrary JSON
structure gets passed around internally at great expense (since it
is copied to every new content browser with initialProcessData.)

I have a suspicion the function is a leftover from the days before
capabilities negotiation was done in geckodriver. Since it doesn’t
do any matching it would be prudent to rename/rewrite it to the
effect it’s clear it only deals with picking up configuration passed
by geckodriver.

(Edit: Part of the comment went mysteriously missing.)