It looks like the only way to reproduce this is to
1. disable all "MultiDevice" flags and reset, 
2. open the settings via chrome://settings, and
3. leaving the tab open, sign out and sign back in.

The SmartLock settings disappear. However, if I open up the settings in a new tab or via the Settings gear, the SmartLock settings are there. After opening a new settings page, if I refresh the old tab, the SmartLock settings reappear there as well. Note: refreshing the old tab before opening a new settings page has no effect.

The reason the settings don't appear on the old tab is because |easyUnlockAllowed_| (https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/people_page/lock_screen.js?l=119&rcl=cd9fed5920bf6185cd5e13b4bb0ac45e9d1c2b32) was false. Digging deeper, it looks like |bluetooth_detector_->IsPresent()| is false when EasyUnlockService::IsAllowed() is initially called. After adding debugging messages to EasyUnlockService::IsAllowed(), the first ~10 lines of the logs (/home/chronos/user/log/chrome) are as follows:

-----------------------------------
[17058:17058:1015/153037.154218:VERBOSE1:easy_unlock_service.cc(276)] EasyUnlockService::IsAllowed():
shut_down_: 0
IsAllowedInternal(): 1
bluetooth_detector_->IsPresent(): 0
[17058:17058:1015/153037.165032:VERBOSE1:component_updater_service.cc(90)] CrxUpdateService starting up. First update attempt will take place in 360 seconds. Next update attempt will take place in 18000 seconds.
[17058:17058:1015/153037.166062:ERROR:component_extension_ime_manager_impl.cc(140)] IME extension file path does not exist: /usr/share/chromeos-assets/input_methods/xkb
[17058:17058:1015/153037.166195:VERBOSE1:arc_app_list_prefs.cc(871)] Default apps ready
[17058:17058:1015/153037.166624:VERBOSE1:arc_app_list_prefs.cc(384)] Registering host...
[17058:17058:1015/153037.166649:VERBOSE1:arc_app_list_prefs.cc(980)] App instance connection is closed.
[17058:17058:1015/153037.207856:INFO:remote_device_loader.cc(141)] Derived keys for 16 devices.
[17058:17058:1015/153037.319827:VERBOSE1:easy_unlock_service.cc(276)] EasyUnlockService::IsAllowed():
shut_down_: 0
IsAllowedInternal(): 1
bluetooth_detector_->IsPresent(): 0
[17058:17058:1015/153037.368465:VERBOSE1:easy_unlock_service.cc(276)] EasyUnlockService::IsAllowed():
shut_down_: 0
IsAllowedInternal(): 1
bluetooth_detector_->IsPresent(): 1
-----------------------------------

This seems like an edge case since it requires that you already have settings open from a previous session, then you log out and back in again. Downgrading to P2 for this reason.

If you leave the settings *window* open instead of a browser tab pointed to chrome://settings, does this still reproduce? If so, we should still fix this issue. If not, it's probably not worth our time to fix since users are not expected to access settings through a browser tab.

The settings window doesn't stay open after signing out and signing back in, so I haven't seen any issue there. I agree that this is lower priority.

To be clear, this bug is only concerned with the case where the "MultiDevice" flags are disabled on the chromebook.

There is a separate issue regarding the case where the user has the "MultiDevice" flags *enabled* on the chromebook, but BETTER_TOGETHER_HOST is not yet supported or enabled on any phone. In this case, the user will currently not see legacy SmartLock setting on the chromebook. (See https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/people_page/lock_screen.html?l=176-177&rcl=b03ffb6b8056961fdbd373de1a4cb35719acfaa8). This is being addressed in  https://crbug.com/895585 .

I don't really think this is worth our time to fix at all in that case. Thanks for investigating and clearing this up, Josh!