Currently, forcedBlockProtectionExceptionList allows defining exceptions based on target blocks and interaction types (like hand$ or break$), but it doesn't support conditions based on what item a player is holding.

Proposal:
Add support for a syntax that specifies both the required held item and the target block, using a format like:
<item_id>{<nbt>}$<block_id>

Example use cases:
Allow interacting with a blaze burner only when holding a create shopping list:
"create:shopping_list{}$create:blaze_burner"

This would provide much more precise control over protected interactions, especially for modded setups where specific items need to interact with specific blocks.
Thank you for your consideration and for all your work on this great mod.

Thanks for the suggestion. Definitely not going to include NBT but I can consider item IDs.
But I still doubt that it's even necessary.
What would be wrong with adding a normal interaction exception for blaze burner and a separate item use exception for the shopping list? That would allow using the shopping list on the blaze burner as well as other blocks that can be interacted with. Only other items with exceptions would be possible to use at the blaze burner.
Is there anything specific that would go wrong on your server with that?

Hi Xaero, thanks for the suggestion. I understand that combination would technically permit the interaction I want. However, it would also create a lot of unintended permissions because it links two broad permission pools together.
What I'm looking for is not just to allow the shopping_list + blaze_burner interaction, but to restrict it.
The current system only allows for broad 'can interact with anything in list B' rules. The proposed item_id$block_id syntax would allow for a specific 'can interact only with this one thing' rule, which is what's needed for custom game mechanics like this shop system.

I understand your suggestion. I'm asking if you know of a real example where adding 2 separate exceptions would be a problem, because I don't, which is why I never added this type of exceptions.

I do have a concrete example that illustrates the potential problem.
Let's say I follow your suggestion and set it up like this:
I add a general interaction exception for the blaze burner to allow the shopping list.
I add a separate item-use exception for the shopping list to allow it to be used on the blaze burner.

This works perfectly for my shop. Now, imagine I install a gravestone mod. I want players to be able to use a key on a gravestone to clean it up in my claim, preventing my land from becoming a cemetery.
I add the key to the gravestone's general interaction exception list.
I add the gravestone to the key's separate item-use exception list.

By doing this, I've now also allowed the key to be used on the blaze burner!
This creates a non-intuitive link between two completely unrelated systems. Now, any player with a gravestone key can interact with my blaze burner, potentially accessing my entire storage and automation system, which is a massive security risk.

Is this an actual situation? How would they access your entire storage through a blaze burner? Would interacting with the key do anything? I don't know if I'm forgetting something about blaze burners. Let me know if I am.

I understand how this can be a problem in theory, just as you're explaining, but from my experience, it seems like, in practice, Minecraft blocks, whether modded or vanilla, never work in a way where a situation like this is possible. The whole block is either all safe for interaction or not. Same for specific items, they're either safe for use or not. I can't really prove it but that's just what I've experienced so far. If you can prove me wrong, I can prioritize this feature higher than I would otherwise.

Usually when an item is used at a block, it is safe to use at other unprotected blocks as well. Typically, it's a very specific item for a specific block, like your gravestone example, and a different item-block combination doesn't do anything dangerous either.
If a block gives access to some storage, then it usually doesn't have exceptions where only a certain few items DON'T give you access and everything else does (the opposite of a key). If not by default, then by shift-clicking you'll usually still get access to the storage, if that's the default action. So a combo item-block exception, like you're suggesting, would not be safe either.

You are absolutely right, and I want to thank you for your patience in walking me through this.
I did some testing based on our conversation, and you are correct. Using the gravestone key on the blaze burner only opens its GUI, allowing players to see the items but not interact dangerously with the storage system. This is perfectly fine and does not pose the security risk I initially imagined.
I sincerely apologize for proposing the request based on my assumptions before thoroughly testing the scenario. My concern was theoretical and did not hold up in practice, and I appreciate you taking the time to explain the mechanics clearly.

However, I believe the method I proposed might offer a more intuitive approach to configuration, as it was the first solution that came to mind to address this specific need.

Hold on, this is kind of interesting. What gives blaze burners a GUI? Do you have an addon or am I missing something?

Since I'm not a native English speaker, I might have misexpressed this earlier. In Create, when a Blaze Burner is placed next to a Stock Ticker, right-clicking on the Blaze Burner will open the Storage Interface GUI.

I see. You are right, if it wasn't for the integrated Create support, then this would create an unsafe situation. So it is possible after all. Still theoretical but got very close to being real here. And what's interesting is that it does seem to be impossible to open the GUI when you have the shopping list in hand, no matter if I shift-click or not, so it is a reverse-key after all.
I wonder if it's purely client-sided behaviour though and sending a block interaction packet manually would still activate the block (making the concrete item-block exception still unsafe). Will have to test more.
EDIT: I think it would be safe, but we'll see.