In BC18 we have got a new object type named permissionset.
This object type allows to build a permission by including other permissionsets (with property IncludePermissionSets) and add our own on top.

Although, we frequently deploy customers by copying standard permissionsets (like D365 BASIC) where we remove some permissions (like those on G/L Entries and G/L Accounts). The immediate consequence is a important workload when major upgrades occur: new tables are created, customers cannot work until we add these tables on their custom permissionsets.

This could be "easily" solved if we could exclude a permissionset from another.
For instance, I could create a permissionset for G/L Entry and G/L Account tables:

permissionset 50000 "Accounting PTE"
{
Permissions = tabledata "G/L Entry" = RIM,
tabledata "G/L Account" = RIMD;
}

Then I could create my customized D365 BASIC permissionset:

permissionset 50001 "My Basic PTE"
{
IncludePermissionSets = "D365 BASIC";
ExcludePermissionSets = "Accounting PTE";
}

Users with permissionset My Basic PTE would access the same things as D365 BASIC expect the read permission on G/L Account and the read permission on G/L Entry would be removed.
It would mean that permissionset are build this way: First add IncludePermissionSets, Then remove ExcludePermissionSets and finally add Permissions.

This design would permit us to build custom permission sets that easily can be upgraded if Microsoft adds new objects.