Paper/Minecraft Brigadier Command Feedback Parity

Is your feature request related to a problem?

Yes. When writing custom Paper commands using Brigadier, there is no simple way to match how vanilla Minecraft suppresses command output when run via functions (mcfunction), command blocks, or when sendCommandFeedback is disabled.

For example, if I run a vanilla command like /time set day in chat, I get feedback in game chat:
Set the time to 1000

But if I call the same command inside a function:
/function namespace:day
Then Set the time to 1000 is not shown at all.

This means that individual commands in the function do not send feedback to the sender (player who ran the function).

If I create a custom command that uses:

ctx.getSource().getSender().sendMessage("My custom command set it to day");
and run it via a function, the feedback is always shown, regardless of context or gamerules. This breaks parity with vanilla behavior.

There is no clear way in the current API to handle command output suppression the same way vanilla does.

Describe the solution you'd like.

Expose a new API on the command sender (or CommandSourceStack) like:

ctx.getSource().getSender().sendFeedback("My custom command set it to day");
This method should:

Only show the feedback if it matches vanilla command feedback rules (i.e. not inside mcfunctions or command blocks, and only if sendCommandFeedback is enabled).
Internally handle all the context-checking and feedback suppression to match vanilla commands.

Describe alternatives you've considered.

Manually checking sender type/context: Not reliable, as mcfunction execution context is not exposed in the Paper API.

Reading the sendCommandFeedback gamerule and guessing context: Not possible to do cleanly or consistently from plugins.

Using sendMessage: Always sends feedback, which breaks vanilla parity.

Other

sendFeedback() is just a suggested example—if there’s already something built in to the vanilla command system that can be exposed to plugins, that would be even better.

Start by reviewing the proposed behavior in this issue and the linked pull request #13058, then trace the existing command sender or CommandSourceStack APIs mentioned here. Done means custom command feedback follows vanilla suppression rules for functions, command blocks, and the sendCommandFeedback gamerule.