It seems that developers, including myself, do not expect that SetRecFilter() will use a secondary key if one is active; intuition suggests that it would always filter to the current record, i.e. use the unique primary key.

I reported this here and got the documentation improved to mention that it might filter on a secondary key:
-> https://github.com/MicrosoftDocs/dynamics365smb-devitpro-pb/issues/1789

Another dev has run into the same unexpected behaviour here, after doing SetRecFilter(), if the user has sorted on a secondary key, which turns out to break the code/logic:
-> https://www.yammer.com/dynamicsnavdev/#/Threads/show?threadId=493934787551232

It might help to add an optional parameter, `ForcePrimaryKey`, defaulting to `false` to preserve current behaviour, but if `true` ensuring the PK will always be used regardless of whether the view uses a 2ndary key.

Then we could at least protect our code against the latter possibility and self-document that we don't wish to use 2ndary keys. By getting into the habit of doing SetRecFilter(true) we would avoid the possibility tripping us!

Thanks for considering.