User profile "notifications" page always shows data of logged in user, regardless of uid in the url

I see similar behavior in my installation. in my case, I think the discrepancy comes that although the "title" says "John Smith Follows", the body is actually showing the information for the logged in user. The body stays the same no matter what uid is in the URL user/[uid]/notification-settings. Whereas the title does change to reflect the URL, showing "John Smith Follows" for that user vs "you follow" for the logged in user.

So I'm guessing it's a configuration in the view that displays the info.

@behoppe333, let me know if you think I'm taking over your OP if you think your issue is not the same.

I found reference to similar behavior in #2001702: Message Subscribe sends emails regardless of flag checkmarks in notification-settings of always showing the groups followed by the logged in user even when claiming to be for another user. The issue was supposedly fixed for Commons 3.3, but I am still seeing the problem.
The fix in #3 of that issue at https://drupal.org/comment/7483678#comment-7483678 does pass the user object $account as an argument to the relevant functions, but then the view itself (e.g commons_follow_node) is not configured to expect a uid as an argument.

This is the original view configuration which does not have any user relationships and indeed displays flags "by current user"

Here is the modification I made to incorporate the user argument (according to instructions I found in an unrelated issue #1191228: Display Nodes Flagged by a Given User (rather than current user) in a View )

This change is giving me the behavior I expect when I visit user/[uid]/notification-settings.

I'm not sure if this is the right fix for the issue. I see that in message_subscribe_ui.module

 function message_subscribe_ui_tab($account, $flag_name = NULL)
....
$view->set_arguments(array($account->uid));

so the uid is attempted to be passed programmatically rather than by the uid in the URL.
but all the same it does seem that the view is not receiving the argument with the original configuration.

I found this related issue #1920824: Admin viewing another user's notification settings tab shows admin's notification settings that discussed this same issue. The conclusion there seemed to be that another solution would be to disable anyone (ie. user1) from viewing another user's notification-settings page at all, rather than dealing with fixing the relationship and contextual filters of the flag/view code. There is a patch at that issue, which I have not yet tested.

Please focus on this fix: #1920824: Admin viewing another user's notification settings tab shows admin's notification settings