Today, experimental features in blink is applicable toward all the layout tests, whereas only a subset of tests rely on experimental features.

This is problematic, because:
i) It mysteriously changes behavior due to turning on certain features, leading to lots of delay while debugging (from chrishtr@)
ii) There are a number of abandoned features in the "experimental" or "test" state, and turning them off takes work because it causes some tests to fail. (also from chrishtr@)
iii) It also make the test binary diverges from what we ship to users (due to the behavior change mentioned in (i)

The thread in https://groups.google.com/a/chromium.org/d/msg/blink-dev/1hgFn1oTEvU/adSPLugsCAAJ proposes two solutions that are favorable by blink devs:

1) Put strict limits on the time a feature is allowed to be tested-but-not-shipped. Proposal: should ship in the same Chrome major version in which tests were flipped to test the feature. Any earlier testing should be done with techniques such as virtual layout test suites or RuntimeEnabledFlag override/TEST_P patterns in unittests.

2) Separate "test" from "experimental". "experimental" would merely mean --enable-experimental-web-platform-features turns on the feature. "test" means on for testing. They can be turned on separately.