In a sense the question is whether access_method should classisy the client, or the server response.

• client - Classify whether the client advertises itself as a "mobile" device, or
• server - Classify whether we served a "mobile" formatted version of the page.

Today, we mostly do "client", because Varnish decides whether to redirect traffic to m-dot, and the refinery then uses .m. to compute access_method. This means for edge cases like en.m.wikipedia?useformat=desktop and en.wikipedia?useformat=mobile we classify them today based on the hostname, not based on the served format. On the other hand, for cookies we do it the other way around. I doubt this was intentional, but indeed if you opt-in to the m-dot cookie from a desktop browser, or opt-out from mobile on a mobile device, we happen to classify your chosen experence, ignoring the user-agent, because these cookies redirect you to/from mobile (unlike the query parameter). So we're not consistent today here.

There are two more reasons for Option 1:

• Today we compute access_method in the wmf.webrequest dataset regardless of is_pageview. This means we can analyze traffic patterns, to not just for pageviews, but also for thumbnails on upload.wikimedia.org, and API requests to /w/api.php and /w/rest.php, using access_method as a way to group by access method. I don't know how important these use cases are, but, by opting to set this in Varnish, we keep this largely the same as today and thus don't need to consult/migrate these queries, thus leading to a quicker decision. If there is merit to change this, I think we can do that a separate task outside the critical path of T389696: Analyze impact for webrequest and unique devices pipelines to derive access_method without m-dot domain. For example, we could end up with a hybrid where MobileFrontend sets it on pageviews to 1 or 0 and leave it to Varnish to classify the rest.
• Jon has voiced a desire to phase out MobileFrontend within the coming year. And, as James points out, Wikifunctions already doesn't have MF installed. In a future where MobileFrontend doesn't exist, and pageviews use a responsive skin without server-side variations, there would no longer be a server-side place to set ismobile=1 (it'd be expensive to vary the CDN on this, just to add a single header from MediaWiki PHP). In that future, we'd almost certainly revert back to wanting to classify the client, as there'd no longer be a server-side format difference.

This is now live.

$ curl -I 'https://en.m.wikipedia.org/wiki/Main_Page' -H 'X-Wikimedia-Debug: 1'
…
x-analytics: …;https=1;ismobile=1;debug=1;…