Yes, I agree that message carbons is the right way to implement it as a separate plugin. Though, rcollier is correct that it should be supported by the server as well as the client. At the moment there are not so many clients that support it.
As for the option of broadcasting all incoming messages to all connections sharing same bare JID, I think it should be implemented as a plugin (better than a patch and a server true/false option). But it should be pointed out that it’s a ‘patch’ and not the behaviour by specification.
Speaking of the plugin to broadcast messages (not XEP-0280 Message Carbons) it should be noted that it can be used for incoming messages only but not to distribute own outgoing messagse to all your devices. As for the later I think the client should support message carbons as not all of them will process plain messages correctly even if the servers sends a message to the client. It will have a different ‘from’ field from the full JID that particular resource has (it will be his own JID but with a different resource).
I’m willing to implement this patch to deliver messages to all user resources no matter whether the message was sent to bare or full JID. Though, I don’t have experience creating plugins for Openfire. If you can think of a way to implement it, please advise me. I’ll share the code with the community if I manage to do it the right way (plugin not a patch). I’m pretty sure it will be a pretty popular feature based on all the requests and questions regarding it here.