There are a few remaining places where expiry support should or could be added:

• ApiEditPage — This is what would be used when editing within VisualEditor, for instance. The code seems to trace through the EditPage class, and the watching happens with WatchAction::doWatchOrUnwatch(), which is probably being updated as part of T245565: Watchlist Expiry: Support for Static Watch Page (action=watch) [medium].
• ApiBlock — The use-case is you can watch a user's talk page after blocking, say to monitor for unblock requests. I do see value in supporting expiries. The code seems to trace to the SpecialBlock class, where it calls WatchAction::doWatch() which already accepts an expiry. So having the API accept an expiry is probably not hard.
• ApiProtect — There is an option to watch the page at the same time as protecting it. I think adding expiry support would be useful for admins, and fortunately it doesn't seem very hard; just add the new parameter, update ApiBase::setWatch() to accept it, and pass it to WatchAction::doWatchOrUnwatch().
• ApiDelete — Same as with protect; we just need to adjust the API to accept the expiry and pass it to ApiBase::setWatch().
• ApiRollback — Ditto, should be straightforward.
• ApiMove — Ditto.
• ...?

Important notes:

• The block and protect APIs already have an expiry parameter (for the block expiry and protection expiry, respectively). For this reason I suggest all APIs be consistent and use the same name for the watchlist expiry parameter, something like watchlistexpiry. I think it's OK that the watch API (which we've already done) uses just expiry, though I suppose you could also support watchlistexpiry as an alias.
• In the preferences, there are options to automatically watch pages for each of the above actions. Adding support for expiries to those can be done separately. The above code changes would only apply when the watchlist parameter is given a value of "watch" (user explicitly says they want to watch the page), as opposed to "preferences" (the default, goes by your preferences).
  • Further to this point, there are separate watch preferences for creating pages and editing existing pages, hence they may ultimately have separate preferences for the expiry. I don't think this will present any challenges since this happens transparently (when editing, if it's a new page it'll refer to that preference, rather than the "edit" preference). For the scope of this task, we're only concerned about when the user explicitly says they want to watch the page instead of falling back to preferences.
• With all these changes, it really invites the idea of introducing a standardized parameter type for expiries to the action API. That is something we can work on later (or not at all). Related work is tracked at T248196: Consolidate logic for parsing expiries. For now just use a PARAM_TYPE of "string", and use WatchedItem::normalizeExpiry() to parse the expiry input, just like we did at https://gerrit.wikimedia.org/r/580522.