There are 34 open tasks tagged with both Recent Changes and Watchlist
https://phabricator.wikimedia.org/maniphest/query/4ZnqTqvp8dLR/#R

The degree to which it makes sense for our team to work on both features simultaneously:

T163429: Provide UI for paging through Watchlist and Recent Changes results in the JS-enhanced UI

UI:
The non-JS enabled UI is different between RecentChanges and Watchlist.
JS enabled UI could be a shared component the same way the current shared buttons are. (ex: ChangesLimitAndDateButtonWidget)

BUSINESS LOGIC:
In the pagination example each of the classes: SpecialRecentChanges.php and SpecialWatchlist.php both extend ChangesListSpecialPage which controls the rows of data that are displayed getRows
and is the class where we would need to make changes to support pagination.
In this case we would need to update both Recent Changes and Watchlist at the same time.

T11790: Watchlist doesn't show prior entries to a page when the filters are set such as the current revision of the page is selected to be hidden
UI:
No UI changes needed for this ticket.

BUSINESS LOGIC:
Similar to the pagination example each of the classes: SpecialRecentChanges.php and SpecialWatchlist.php both extend ChangesListSpecialPage which controls the rows of data that are displayed getRows
and is the class where we would need to make changes to. Though this ticket is specifically addressing Watchlist-so I'm wondering if we want this behavior in both places?
Breaking this one out in to separate tickets depends on if we want the functionality in both places or only in Watchlist.

T234151: Provide an option to filter "marked Foo for translation" in Watchlist and Recent changes

UI:
No UI changes needed for this ticket.

BUSINESS LOGIC:
There is also a parent function that is called in each of the child classes: SpecialRecentChanges.php and SpecialWatchlist.php called registerFilters https://gerrit.wikimedia.org/g/mediawiki/core/+/26b6bf6017ae305ad529dddec4e429603befde8f/includes/specialpage/ChangesListSpecialPage.php#1010
where we could make the updates if we wanted to add it to both screens at the same time.

T149558: Watchlist and recent changes edits in the same minute are sorted wrong.

I was unable to reproduce this bug :( so I cannot say whether the changes can be lumped together.

Would such requests be double the workload, or would making the requested change inherently apply to both interfaces, or somewhere in between?

I think it's somewhere in between.
I think for the majority of use cases making changes in one spot will be sufficient and not add to the workload.
However, the UI is slightly different when JS is not enabled therefore there will be some additional overhead in those cases where the UI is different.
There is also additional logic in SpecialRecentChanges.php and SpecialWatchlist.php that diverges so any changes made to those classes would probably need to be separated into different tickets.

My recommendation

Since we won't know ahead of time, I would keep the tickets seperated and if we can close both tickets by changing code in one place then we get a win!
Since they are technically different features on different screens I would consider them separate enough to isolate them into different tickets/user stories.

In T376130#10210653, @Kgraessle wrote:

There are 34 open tasks tagged with both Recent Changes and Watchlist
https://phabricator.wikimedia.org/maniphest/query/4ZnqTqvp8dLR/#R

The degree to which it makes sense for our team to work on both features simultaneously:

T163429: Provide UI for paging through Watchlist and Recent Changes results in the JS-enhanced UI

UI:
The non-JS enabled UI is different between RecentChanges and Watchlist.
JS enabled UI could be a shared component the same way the current shared buttons are. (ex: ChangesLimitAndDateButtonWidget)

BUSINESS LOGIC:
In the pagination example each of the classes: SpecialRecentChanges.php and SpecialWatchlist.php both extend ChangesListSpecialPage which controls the rows of data that are displayed getRows
and is the class where we would need to make changes to support pagination.
In this case we would need to update both Recent Changes and Watchlist at the same time.

💯

T11790: Watchlist doesn't show prior entries to a page when the filters are set such as the current revision of the page is selected to be hidden
UI:
No UI changes needed for this ticket.

BUSINESS LOGIC:
Similar to the pagination example each of the classes: SpecialRecentChanges.php and SpecialWatchlist.php both extend ChangesListSpecialPage which controls the rows of data that are displayed getRows
and is the class where we would need to make changes to. Though this ticket is specifically addressing Watchlist-so I'm wondering if we want this behavior in both places?
Breaking this one out in to separate tickets depends on if we want the functionality in both places or only in Watchlist.

It looks like this bug is only a thing when Expand watchlist to show all changes, not just the most recent is set https://en.wikipedia.org/wiki/Special:Preferences#mw-htmlform-advancedwatchlist
which should mean that it is irrelevant for recent changes. There's a proposed patch for adjusting the query, but it will impact hook implementations:
https://www.mediawiki.org/wiki/Category:ChangesListSpecialPageQuery_extensions

T234151: Provide an option to filter "marked Foo for translation" in Watchlist and Recent changes
UI:
No UI changes needed for this ticket.

BUSINESS LOGIC:
There is also a parent function that is called in each of the child classes: SpecialRecentChanges.php and SpecialWatchlist.php called registerFilters https://gerrit.wikimedia.org/g/mediawiki/core/+/26b6bf6017ae305ad529dddec4e429603befde8f/includes/specialpage/ChangesListSpecialPage.php#1010
where we could make the updates if we wanted to add it to both screens at the same time.

💯

T149558: Watchlist and recent changes edits in the same minute are sorted wrong.

I was unable to reproduce this bug :( so I cannot say whether the changes can be lumped together.

From looking through related tickets, I think the revisions must have the same second timestamp in the timestamp as well as minute. We could have a spike on this. I suspect that it's a single sorting issue that can be resolved once.

Would such requests be double the workload, or would making the requested change inherently apply to both interfaces, or somewhere in between?

I think it's somewhere in between.
I think for the majority of use cases making changes in one spot will be sufficient and not add to the workload.
However, the UI is slightly different when JS is not enabled therefore there will be some additional overhead in those cases where the UI is different.
There is also additional logic in SpecialRecentChanges.php and SpecialWatchlist.php that diverges so any changes made to those classes would probably need to be separated into different tickets.

💯
I agree that it's a case by case basis; the increase in workload would probably be only be a big problem where we we need to change hooks that have a lot of implementations.

My recommendation

Since we won't know ahead of time, I would keep the tickets seperated and if we can close both tickets by changing code in one place then we get a win!
Since they are technically different features on different screens I would consider them separate enough to isolate them into different tickets/user stories.

💯
Where we want to implement the same feature in two places, I suggest we use a tracking task to hold both.

Thanks both - this is very helpful :)