The portal only allows an external application to request the service from the compositor. He portal does not allow an external application to provide additional functionality beyond what is already provided by the compositor.

In my use case, I want to screen share a specific window, not the whole screen; this is functionality previously provided by a third-party X11-based tool, which cannot be provided from an XDG portal (even on those compositors that support portal at all).

Portals are a really weird thing. They're mostly pushed via the Flatpak/GNOME crowd, and are intended to be cross platform by using an external messaging bus: d-bus (e.g.: they don't use the X protocol and Wayland). The same interface can be used in both Xorg and Wayland, and that's the only upside of portals.

However, their implementation is not meant for native applications and are pretty inefficient. For example, the screenshot portal will save the image into disk and return its path -- so if you wanted to render the image on screen, you now need to read and decode a file. The screenshot is encoded, serialised to disk, serialised FROM disk and then decoded again just to get pixels from the compositor back into the compositor.

Portal really don't make sense if you're writing native wayland clients, since portals just really end up using the wayland protocol under the hood, with two or three services in the middle handing messages over just to expose a "standard" API.