I'd like to echo kbr comment #29 on Issue 736251 (now marked as Fixed) so it doesn't get lost.
If this bug was reproducible by just having a non clean profile, it feels there should really be a test running on the main waterfall that exercises that path.

It looks like the other problem here was this only triggered in official builds. Unofficial builds never create a VariationsService.
https://cs.chromium.org/chromium/src/components/variations/service/variations_service.cc?rcl=86716087cc70f251aad2111ec6d86711239c44ab&l=487

That's probably why I never noticed when testing locally. (I just tried the patch again on a non-clean profile and it was just fine.)

Telemetry bots do official builds but didn't catch this. which suggests that official build is necessary but not sufficient. 

Right, the other half is that it needs to be on a non-clean profile. I was just confused why I didn't notice testing locally and wanted to find out why.

re: comment 4, I'm not sure the presence of VariationsService is relevant.

The problem would be hit if:
  1. Someone first does a base::FeatureList::IsEnabled() query
  2. Then, base::FeatureList::SetInstance() is called registering the instance.

(2) is done in  ChromeBrowserMainParts::SetupFieldTrials() regardless of whether there's a VariationsService.

So I think the main factor was what contributes to (1) happening so early in this specific case? Presumably something in the profile?

The factor for (1) happening so early was precisely the presence of VariationsService. :-P

It calls into //crypto to verify a signature, but only on official builds and only if an existing profile. Hence why I didn't notice this locally (unofficial build) and why the bots didn't notice (apparently we have no test coverage of official build + existing profile?). That //crypto is allowed to depend on //base but secretly can't use part of it is very confusing layering-wise. Thus the dilemma.

Ah, I see! Thanks, that's the piece I was missing.

It is certainly a dilemma. Variations service calls into crypto to validate variations seeds we receive from the server. Even if we enable it for tests, tests should be hermetic and shouldn't be downloading stuff from servers. Hmm.

We could make unofficial builds still start VS but bake in a dummy empty seed, so that the codepaths are exercised.

The dummy seed could be part of a browser test that populates the existing profile with it, so we wouldn't have to necessarily ship it to end users. (Though starting Chromium locally then wouldn't exercise it.)