Was the toggle clickable, or was it disabled? From the look of it, it seems like the toggle was disabled. Have you gone through setup, and were you able to use any of the features?

+1
This toggle opacity corresponds to Easy Unlock being unclickable because it's in one of the following states:

1 PROHIBITED_BY_POLICY
2 NOT_SUPPORTED_BY_CHROMEBOOK
3 NOT_SUPPORTED_BY_PHONE
4 UNAVAILABLE_NO_VERIFIED_HOST
5 UNAVAILABLE_INSUFFICIENT_SECURITY (i.e. you're phone needs to set up lock screen)
6 UNAVAILABLE_SUITE_DISABLED

If you know how to inspect HTML elements I can give you instructions for determining which state it's in. Otherwise, if you have gone through setup and your phone has a lock set up, let me know and I'll investigate further.

I think it wouldn't be because of the phone's lock situation because that's not fully implemented on the android side.

Ah, then I think it needs to be grey and not blue. The grey value when the toggle is disabled. 

Another issue I've observed with the toggles:

Repro:
(1) Go to the subpage and turn Smart Lock off while leaving Instant Tethering off.
(2) Turn off the Better Together suite.

Expectation 1: The Smart Lock toggle should be disabled, and hovering over the toggle should not cause a pointer cursor to be displayed.
Actual 1: The toggle is disabled and clicks are not allowed, but hovering over the toggle causes a pointer cursor to be displayed.

Expectation 2: The Instant Tethering toggle should be disabled, and hovering over the toggle should not cause a pointer cursor to be displayed. Clicks on the toggle should do nothing.
Actual 2: The toggle is still enabled and clicks are allowed. Clicking the toggle briefly animates to "on" before reverting back to "off". Hovering over the toggle causes a pointer cursor to be displayed.

The initial grey/blue issue should not be a problem anymore because turning off the suite now turns off the individual features

The instant tether issue (2) in https://bugs.chromium.org/p/chromium/issues/detail?id=878648#c10 is tracked independently in https://bugs.chromium.org/p/chromium/issues/detail?id=884830&q=component%3AUI%3EProximityAuth%20label%3AM-71&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

I will look at (1) shortly.

To clarify (1):

Both the Instant Tethering row and the Smart Lock row route to their respective subpages in general. As mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=884830&q=component%3AUI%3EProximityAuth%20label%3AM-71&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified the behavior of Instant Tethering will be a little different until I refactor a bit, but I want to understand the desired behavior (which I would implement sooner for Smart Lock)

When Smart Lock is blocked by policy, the chevron is replaced by the enterprise icon and the item does not route away. Do we want the items to route only when the feature is editable or do we want it to route away any time the feature is visible and not blocked by policy?

The only time we should not route the feature to the sub-page is for policy

Jordy, this thread's become a bit hard to follow. Can you enumerate exactly what's left to be done on this issue?

I was just about to extract the relevant parts and mark it a duplicate

After a discussion with jlklein@ offline, I'm closing this bug. The only piece that's not either fixed or part of https://bugs.chromium.org/p/chromium/issues/detail?id=884830&q=component%3AUI%3EProximityAuth%20label%3AM-71&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified is the cursor appearing as a hand instead of an arrow when it's over a disabled. I will discuss this issue offline with shibasheikh@ to see if we want to address it