There are many situations requiring that Chrome sends some specific setting identifier in the initial HTTP/2 SETTINGS frame as an experiment on Dev and Canary channels, with a side-by-side control group.  Such experiments are meant for gathering data and are not intended to be rolled out to other channels (either Beta or Stable), nor are they inteded to be enabled by default on trunk.

Recent examples include:

(1) A certain load balancer product with older firmware is known to incorrectly signal an error if it receives a SETTINGS_MAX_HEADER_LIST_SIZE with value exceeding 32768.  See  issue 751642  for details.  However, Chrome should send a larger value on every connection for performance reasons.  Quantifying the effect of this broken load balancer allows us to evaluate the balance between performance and error rate, so that an informed decision can be made about sending a larger value by default.

(2) Sending SETTINGS_ENABLE_PUSH with value 0 would allow measuring the impact of server push on page load timing, allowing for improved push algorithms, and also helping to evaluate the overall effect of push.

(3) In the spirit of GREASE [1], it would be advantageous to send undefined settings identifiers to make sure buggy servers that would signal an error on undefined settings are detected early during their deployment.  RFC7540 specifically requires that unknown or unsupported identifiers must be ignored.[2]  As of right now, no such server is known to exist.  (While not directly relevant to Chrome sending unknown settings, it is worth noting that there exists at least one buggy client implementation that closes the connection upon receiving an unknown setting from the server in violation with the specification, showing that this kind of bug is not inconceivable.)

[1] https://tools.ietf.org/html/draft-ietf-tls-grease-00
[2] https://httpwg.org/specs/rfc7540.html#SettingValues