Name: while current BKE_library is a mess of various old ugly names, new convention is relatively clear - BKE_library is for operations over *libraries* only. Operation over the whole Main are using BKE_main_id_ prefix.

So BKE_main_id_orphaned_delete() ?

In the end, I think you should only care about local data-blocks in that loop, and use existing BKE_library_unused_linked_data_set_tag() to tag unused linked data? If we actually want to manage linked data at all here, that is…

This should also take care of the 'archipelago' case (when you have a dependency loop between linked IDs, and none is actually used by any local data).

This is fairly unclear to me… Needs some comments about what case this is addressing. Also, ID_REAL_USERS(id) <= 1 is always true here (first if above).

And calling BKE_library_ID_is_indirectly_used() is everything but cheap (loop on bmain inside loop on bmain…). You can alleviate that last point by using BKE_main_relations_create()/_free() around that whole loop (together with not deleting IDs in that same loop, as said in next comment below).

You might then miss some 'closed dependency loop' cases (indirectly linked data used by linked data that is to be removed), but think we can live with that for now.

Deleting an ID after the other is very inefficient. You should rather tag all IDs to be deleted, and then call BKE_id_multi_tagged_delete() outside of the loop.

This uses two different code paths to do the same thing, one to count items to be deleted, one to actually delete them. Not a good idea.

Think the BKE function could easily take such int array parameter, and a bool flag to say 'simulate only'. That way, you could also print an info string about amount of deleted IDs at the end of the exec callback (since that operator might also be called without invoke...).

Just use name you want in menu entry, instead of defining one UI name here and then overriding it in the menu entry.