Here's a few spontaneous thoughts ... not really meant as an in-depth review:

• This is like a step 1, right? It appears the requestAdd/Remove APIs currently add/remove to all activities, so there's no way yet for users to make per-activity launchers?

• I'm a bit surprised that the code doesn't use the existing machinery to filter the launcher list by activity ... couldn't LauncherTasksModel just implement AbstractTasksModel::AdditionalRoles::Activities for launcher tasks and rely on TaskFilterProxyModel doing the rest, just like it works for window tasks? The "shownLauncherList" stuff seems to reinvent the wheel at the lower level, when the overall approach in the libtaskmanager codebase is to have a pyramid of dumb list source models that get increasingly filtered/mangled. Or did you try this and it ran into trouble with the ordering ...?

• Note that there shouldn't be any magic that only makes sense in concert with the specific TM applet, the libtaskmanager API should make sense to someone coming at it cold and obey its users. It has users outside of the TM applet.

This is like a step 1, right? It appears the requestAdd/Remove APIs
currently add/remove to all activities

This is the first step that actually worked. Yes, the add/remove API will get a requestAdd/RemoveTo/FromCurrentActivity.

I'm a bit surprised that the code doesn't use the existing machinery to
filter the launcher list by activity ... couldn't LauncherTasksModel just implement

This happens when someone goes into this blind. I'll see how to make it work with the current filtering mechanism.

Note that there shouldn't be any magic that only makes sense in concert
with the specific TM applet, the libtaskmanager

There is nothing really magic here. Namely, the old API returned urls "serialized" as strings - it still returns serialized data. I don't see a way around this approach (I've tried having it separated, but then you have the problem of what is saved where, and how it should be synced) since the data model expects the client to provide the serialized data instead of providing, for example, a config group or some kind of ID for the model to have a full control of the storage.

Yeah this looks cleaner now :)