Some background:

The root of the problem is the set of changes we implemented in this patchset https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/446517 for issue T154719, specifically per the discussion in patchset 4 https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/446517/4#88

The way things used to work was:

1. User with NPP rights visits Special:NewPagesFeed
2. On the server side, we set a property for pagetriage-lastuse in the user_properties table with the current timestamp
3. When viewing articles, on the server side, we had code that would check the user's options to see what the value of pagetriage-lastuse was. If it was not within the last 24 hours, then a JS config variable called $wgPageTriagelastUseExpired was set to true or false
4. On the client-side, when a user viewed an article, the JS would check the value of wgPageTriagelastUseExpired and then show/hide the curation toolbar.

As discussed in T154719, writing to the user_properties table in the context of a GET request is frowned upon. The first iterations of the patchset to fix this involved updating user_properties via a POST request after listControlNav.jswas initialized. We eventually discarded this idea due to performance concerns.

Instead, we first tried storing the pagetriage-lastuse property in the server-side session, in T203273. This had the appearance of working in local development but did not work reliably across longer periods of time, apparently because we should not be relying on server-side sessions to persist information like this.

Next, we implemented the storage of pagetriage-lastuse in localStorage (also in T203273). LocalStorage will persist the pagetriage-lastuse information in a single browser window (not new tabs/windows), so this led to problems where a user clicks "Review" on Special:NewPagesFeed and they're taken to a new window where pagetraige-lastuse is not set in localStorage, so the toolbar doesn't load. Again in T203273 (patchset https://gerrit.wikimedia.org/r/458550) we made a further fix to set a query parameter so that clicking "Review" from Special:NewPagesFeed would take you to /wiki/SomeTitle?showcurationtoolbar=1.

Overall, it seems like users expect to be able to navigate to articles in any window/tab and have the toolbar show up if they've used Special:NewPagesFeed within the last 24 hours, and our combination of query parameter and localStorage isn't accomplishing this.

AFAICT, after the changes we've cycled through, it seems like the most reliable is to once again store pagetriage-lastuse in the user_properties table, update this value via a POST on listControlNav.js, and conditionally set $wgPageTriagelastUseExpired based on a server-side calculation in the article footer view hook.

There were concerns expressed in 446517/4#88 about performance implications of POSTing this value on each initialization of the listControlNav, but IMO it would be better to do it this way as it will be the most reliable for end users.

Checked in testwiki (and betalabs). To summarize the behavior of the curation toolbar

(1) Curation toolbar will be always present when a user navigates to the article form NPP (via clicking on 'Review' or or on the article link).

(2) Navigating from RC or Watchlist, Contribution - the Curation toolbar will be present depending on a user's last selection.

(3) Curation toolbar is not present when a user just searches an article that in NPP feed.

(4) 'Curate this article' will be present if the curation toolbar is dismissed.

There is no discrepancy in displaying the curation toolbar for User namespace vs Article namespace.

Also, the following is resolved too:

(1) If a user is logged for sometime and has Special:NewPagesFeed open, then clicking on 'Review' will display a page without toolbar.