Purpose: Keep track of what can be done for future, risk of blizzard breaking it, user friendliness, etc.

Either just edit this issue, or if it gets messy create text file and commit it.

1. Whisper share

Players: A, B

A: Manual request
B: Parse A's name, send whisper with data payload
A: Filter B's message from being visible and parse payload

Part of this was implemented in Com.lua (module is just dead code right now). Issue back then was that I tried to use Addon chat channel, but it only worked for connected realms via whisper. (The idea was to get all targets to whisper via briefly enabling friendly nameplates.) For limitations see SendAddonMessage

So the idea is to use SendChatMessage since it's not limited by connected realm, and to register the payload parser in the chat filter added by ChatFrame_AddMessageEventFilter.

Note that the sent message can be hidden by filtering on CHAT_MSG_WHISPER_INFORM, but if the option to add whispers to a new chat frame is used then a new frame will be created. It won't contain any text, but the communication will leave a persistent change in the GUI. Below snippet seems to remove the tab again. Be aware that this needs to run on both sender and receiver, and it must not close any existing chat windows.

for _, chatFrameName in ipairs(CHAT_FRAMES) do
   local chatFrame = _G[chatFrameName];
   local name = FCF_GetChatWindowInfo(chatFrame:GetID());
   
   if name == "OtherPlayer-SomeServer" then
      FCF_Close(chatFrame);
   end
end

Risk: I don't know if the filter callback comes with limitations in retrieving the message, but don't expect it.
Risk: Disable by default? Is it considered intrusive for the sharing player? Will it mess with their chat history/last whispered player/ etc.?

2. Emote share

Well, exactly same as old behavior with auto-replaying in chat, but use CHAT_MSG_EMOTE instead.

Risk: Blizzard will probably break it like how they did with CHAT in 8.2.5 if ppl start using it for automated communication, so this is wontfix, same as #40.