MyWarp already provides permissions that override a warp's state to allow users to view, use or modify it even if they the warp is not public, they are not invited and do not own the warp:

mywarp.override.view
mywarp.override.use
mywarp.override.modify

mywarp.override.*

These permissions always override all existing warps, it is currently impossible to override a single warp. While generally a single warp should be treated using invitations or by becoming the warp's creator, there are setups where a permission-based system might be needed.

This could be introduced using delegation such as:

mywarp.override.view.[WARPNAME]
mywarp.override.use.[WARPNAME]
mywarp.override.modify.[WARPNAME]

Existing permissions would simply be a container for all per-warp permissions and continue to work as before.

The main problem with this approach is that implementations with explicit permission-inheritance (such as Bukkit) require a manual registration of the warp's permission when the warp is created or removed. This could be done in a ForwardingWarpManager implementation using a yet to create PermissionService.
Perhaps it is also a good idea to remove state checks (isUsable(LocalEntity) etc.) from Warp altogether since they should not work different between Warp implementations.

This is awesome.

one comment is about the .view and .use separation. Although there may be times when you would want some one to only view a warp I do not think there would ever be a time when someone has use of a warp and would not be able to view it. Unless of course the .view.[warp] portion of the override is viewing the "/warp info [warp]".

If when you give a .use.[warp] the warp will show up in the list of the player when using "/warp list" then there is nothing further needed. If the .view.[warp] perm is however needed in order to see the warp in the "/warp list" then the .use.[warp] perm grant should include the grant of .view.[warp] otherwise you are doubling the permissions needed for a player to see and use a warp.

The other question I would pose is, are you going to put a flag in the config to implement per warp permissions for public warps?

I just had another thought, since you already have permissions per warp set up using invitations for private warps, rather than remaking the wheel, why not just add a flag in the config to require invitations for public warps. If set to true, then the group invitation, player invitation system you already have would adequately allow limitations to public warps.

I personally do not see a need to require involvement of bukkit superperms any further than you already have them. There is just the need to limit player use of public warps.

Sorry for the lack of updates.

After thinking about per-warp permission overrides once more, I have decided against adding them: Taking per-platform permission inheritance into account is just too much work for too little effect.

I think there is a general misconception in the scenario you described regarding public vs. private warps:

• Public warps are always accessible by everyone by design. It is probably better to think of them as unrestricted warps.
• Private warps are restricted in the sense that not everybody can use them.

Implementing any system that blocks access to public warps does not make any sense give these definitions.

I see however that users might want to display private warps under certain conditions. I will implement this with #63. In fact the foundation is already there: The rewritten DynmapMarker class makes no longer any assumptions about the warps it displays. Instead a Precondition<Warp> given upon creation controls which warps are displayed, changing which warps are displayed is therefore as simple as changing a single line.