So for PEX 2.0 we lost the ability to use wildcards in the middle of permission node. This can be useful when you have multiple arguments in a single permission node. An example could be damage.entity.from.damagesource or break.block.using.item. These are only examples, and personally I have permission nodes that might take something like 4 arguments, making it even worse to manage.

break.block.*.item would be the same as break.block.* so there's really no reason to have break.block.*.item.

Remember to negate unwanted nodes above wildcards.

I think item might've intended to be a placeholder -- so break.<block>.using.<item> might be a better example. Regardless, this is an issue that is worth consideration.

Throwing some implementation ideas out there (mostly for myself), this would require having "unmatched" children values, so if the actual permission didn't have a set value the resolution code would go up the tree and see if any 'wildcard' nodes had children with appropriate/stronger values set.

My gut feeling is that a trivial implementation of this would not be that great performancewise due to the extreme potential for backtracking (possibly for a lot of levels), but some degree of optimization would be possible (caching results, marking in child nodes whether any of their parents have defaults (but making updates to the tree more expensive), etc). If anything stops this from being implemented, it's going to be performance issues, but I'd have to make an implementation and profile it in comparison.

Adding this functionality would assign special meaning to the * node segment again, and could allow for users granting node but none of its children by denying node.* as a side effect.

Unfortunately PermissionsEx is currently unmaintained and no further updates are planned. Because of this, all pull requests are being closed. If you are looking for an actively maintained permissions plugin, take a look at LuckPerms. It is compatible with major server platforms and can import data from PEX.