@Kipod, I'm afraid a comment on a task that got resolved 8 years ago will not have much of an effect. Nobody is actively working on this any more. CatWatch got archived. Quite a few of the subscribers here are not even in the same organisation any more.

two issues here.

1. the task itself is a mistake (i.e, "design bug):, IMO. when someone adds a hidden category to their watchlist, they expect to see changes (addition and removal of pages from the cat) regardless of the "show hidden cat" preference: the preference should control whether or not the hidden categories appear in the "categories" box at the bottom of the page, but not block watch items. if dev insists on the current (wrong) behavior, at the very least, these should happen:
   1. i when a user adds a hidden category to their watchlist, they should be notified that they will not see changes in the category without turning on the non-default "see hidden cat" preferences.
   2. similarly, when a user turns on the "show changes in cat" filter, they should be notified that they should be warned that they will no see changes to hidden cat.
   3. when a category is made "hidden", users who are watching it unexpectedly stop getting notified when pages are added and removed
2. the implementation itself is buggy: the bug here is that changes to hidden cats are not shown but they are counted. in the "error sate" watching a hidden cat while the preference to see hidden cats is off), if my watchlist is configured to show 100 changes, and someone does something radical which fills or empties such a category with more than 100 pages), the watchlist will show empty, i.e., the hidden cat changes push other changes out of the watchlist (i.e., they are counted), but are not shown. this behavior contradicts the normal/expected filter behavior: changes filtered out of the watchlist are not counted, and the list shows the maximum number of changes which do pass the filter.

https://gerrit.wikimedia.org/r/281195 mentions 3 bugs as possibly being fixed, including this one. Since there was no response after that I assume we can close this here as well. Please feel free to re-open the ticket or submit a new report if there is still an issue.

In T132568#3117540, @Addshore wrote:

Stalled pending resuming work here once wl_id is deployed on wmf sites (T130067).

wl_id now exists but this is still stalled.

Stalled pending resuming work here once wl_id is deployed on wmf sites (T130067).

Change 278859 merged by jenkins-bot:
Refactor database-related code in ApiQueryWatchlistRaw

Change 284169 merged by jenkins-bot:
Refactor database-related code in ApiQueryWatchlist