Specifically what info are you looking to persist in known_user for kiosk sessions?

I did a bit of digging. IsUserNonCryptohomeDataEphemeral() originally worked exactly as you would expect: It returned |false| for public sessions (kiosks did not exist yet at that time). See the commit message for a description of how it should work:

https://chromium.googlesource.com/chromium/src/+/bdee4043b5f4167fa94c6f9576cb4de7fcfbda4b

Public sessions were handled by line 587. It called FindUserInList(), which looks through the list of all users (regular and device-local):

https://chromium.googlesource.com/chromium/src/+/bdee4043b5f4167fa94c6f9576cb4de7fcfbda4b/chrome/browser/chromeos/login/user_manager_impl.cc#587

This was changed to call a new UserExistsInList() method instead in 2013. That method looks at regular users only, which is wrong:

https://codereview.chromium.org/63173012/diff/230001/chrome/browser/chromeos/login/user_manager_impl.cc

I cannot tell from looking at the CL why this change to the way we handle public sessions was made. It introduced a bug though that we only noticed now, four years later.

+antrim@, do you remember? You wrote that CL four years ago...

Assigning to antrim@ to clarify.

As far as I can remember that CL fixed a bit of cleanup logic. 
Main problem was that the cleanup had to be performed during user list initialization (in GetUsers()), and orginal FindUserInList() required user list to be fully loaded, so it was replaced with lighter UserExistsInList() call.

Lack of Device-Local accounts in that list is definitely an error that slipped through test coverage, and, probably, I did not know a lot about device-local accounts in that time.

Should I fix it now?

It would be nice to fix this, but I am concerned that all sorts of things may depend on the incorrect behavior by now. Maybe you could send a fix through the bots to shake out failing browser tests? That would be a good metric for the start.