In client/server applications backward compatibility is typically defined as the ability of an older client to connect to a newer server. In other words, when a new server is released it is still compatible with the older, already-released clients. Your use-case deals with forward compatibility where you want a newer client to talk to an older server. See more here.
We've long worked to maintain backward compatibility but only recently sought to enable forward compatibility as that is generally the less common use-case. See this JIRA. Looks like the work we did there either doesn't cover the server you're using or something has broken between those changes and the release of 2.4.0.Final.
In any event, JMS is an API specification. It doesn't define a wire protocol which means that JMS implementations (even different versions of the same implementation) are not necessarily compatible with each other. For example, you can't take the ActiveMQ JMS client library and talk to HornetQ with it and vice-versa.
UPDATE: Ignore this. This approach clearly isn't going to work.
Understood, thanks for the clarifications. What do you think the ramifications would be of trying to swap out the Wildfly 2.4.1 HornetQ libraries with 2.2.14? I may give that a try, but suppose it works for my use case...should I be concerned about any other potential problems that might not be readily apparent?
A straight swap of libraries will almost certainly fail because the messaging subsystem is fairly tightly coupled with the version it ships with. However, you could create a new module and use that module from your application. The drawback here is that you wouldn't be able to use any JMS-specific container-managed resources which would rule out using a pooled-connection-factory (which is leveraged by MDBs).