What I did:

Registered a command that runs `Bukkit#dispatchCommand`:

public final class BukkitTestPlugin extends JavaPlugin {
    @Override
    public void onEnable() {
        getCommand("dispatch").setExecutor(new CommandExecutor() {
            @Override
            public boolean onCommand(CommandSender commandSender, Command command, String s, String[] strings) {
                Bukkit.dispatchCommand(commandSender, String.join(" ", strings));
                return true;
            }
        });
    }
}

Join as a player with operator permissions and run these commands (just the first example I found):

/setblock 50 50 50 glass
/data get block 50 50 50
/dispatch data get block 50 50 50

Expected result:

On 1.21.1, running `data get block 50 50 50` works the same whether the player directly runs it or `Bukkit#dispatchCommand` runs it. Since the block at `50 50 50`, is glass, which is not a block entity, the command sends a failure message explaining that.

Actual result:

On 1.21.3, running `data get block 50 50 50` through `Bukkit#dispatchCommand` does not send the failure message as expected.

Notes:

As mentioned at the bottom of SPIGOT-7945, I noticed that `VanillaCommandWrapper` was given a check for `CommandSender sender instanceof EntityPlayer player`. As far as I can tell, `EntityPlayer` does not implement `CommandSender`, and `EntityPlayer` does not have any subclasses, so this check would never be true. I believe this line was supposed to be `sender instanceof Player` or `sender instanceof CraftPlayer` (`sender instanceof Player` and later casting to `CraftPlayer` matches the style of the other `instaceof` checks in this method (except for entity for some reason), though it could cause a `ClassCastException`, not that that's a real concern since other classes extending `Player` is unsupported).

Since `sender instanceof EntityPlayer` is always false, players get treated as entities. This did resolve SPIGOT-7945, but I wondered if the `CommandListenerWrapper` for entities and players differed in any important way. Looking at the source, the `ICommandListener` for players implements `sendSystemMessage` by forwarding the message to the `EntityPlayer`, while entities do not do anything when `sendSystemMessage` is called. Therefore, messages like `The target block is not a block entity` do not get sent to the player when using `Bukkit#dispatchCommand` as mentioned previously.

I also noticed that entities always have permission level 0 while players have a `getPermissionLevel` method, and there was a bit of a difference in the server parameter. I haven't checked whether these differences cause any issues, but the resolution for those would probably be the same for the `sendSystemMessage` problem showcased here. `VanilliaCommandWrapper` should probably be using `((CraftPlayer) sender).getHandle().createCommandSourceStack()`, as it did in previous versions.