Basically I want to get rid of this step

4. The request contains an Accept-Language header with a language
    that matches (exactly or loosely) one of the application languages.

The context is "fr-ca" : a bunch of french speaking people in a sea of English speaking territory.
Official language of business is french.
A lot of computer system are in English. Like 50/50.
Among other things choosing English software help to search on web for settings/feature XYZ.

Basically the language of the os/browser is disconnected from user intent. Most of our target user don't have any idea about advanced settings to adjust asked language.

Then I realize Scheme1 without step4 is almost Scheme2 + cookie.
So I tried to implement cookies in DetermineDefaultLanguageFromRequest delegate.
Not complex but also a failure. This is because whatever the ouput of this is hidden as being the default.
I tough this was a bug until I see it documented:

The default URL Localization scheme (Scheme1) will show the language tag in the URL always; 
an alternative scheme, Scheme2, will show the language tag only if it is not the default.

So basically the feedback is stuff is glued together.
Url presentation is tied to language detection source.
Cookie language detection is tied to request language detection.

So it would be nice to have separate Boolean for behavior.

DetectLanguageFromCookie
DetectLanguageFromHeader
HideDefaultLanguageInUrl

Sheme1 could map as (true,true,false)
Scheme2 map as (false,false,true)

And after setting the scheme we could refine the behavior