I've kept digging around the internet....and I think I've answered my own question.
Now I need to go back to the application/device owners/developers and see what we can do or further lock these devices down to their own VLAN.
Please leave comments or answers with any further advice.
RFC 4541 2.1.2:
Packets with a destination IP address outside 224.0.0.X which are
not IGMP should be forwarded according to group-based port
membership tables and must also be forwarded on router ports.
This is the main IGMP snooping functionality for the data path.
One approach that an implementation could take would be to
maintain separate membership and multicast router tables in
software and then "merge" these tables into a forwarding cache.
Packets with a destination IP (DIP) address in the 224.0.0.X range
which are not IGMP must be forwarded on all ports.
This recommendation is based on the fact that many host systems do
not send Join IP multicast addresses in this range before sending
or listening to IP multicast packets. Furthermore, since the
224.0.0.X address range is defined as link-local (not to be
routed), it seems unnecessary to keep the state for each address
in this range. Additionally, some routers operate in the
224.0.0.X address range without issuing IGMP Joins, and these
applications would break if the switch were to prune them due to
not having seen a Join Group message from the router.
Generally speaking, for IGMPv3 to work correctly in an IGMP snooping environment, all devices should support IGMPv3 (even if they are treating IGMPv3 joins as IGMPv2 joins). This includes the source/router, the host and all devices in between the two.
If the switches doing IGMP snooping do not support IGMPv3, this can potentially cause problems, but this will vary depending on the vendor and/or version of code.
Someone please correct the below if I am wrong, as I have not tested this setup, however I believe my understanding is sound. A bit concerned because I feel I confused myself in trying to type it up.
In your example, assuming the switch that is doing IGMP snooping supports IGMPv3, and that both G1,S1 (Host1's include) and G2,S2 (Host2's exclude) are the same, then it should forward all multicast for that group down to the hub (no matter the source). Since a hub then repeats all traffic on all ports, this results in both hosts receiving all traffic for the multicast group and requiring both hosts to ignore unwanted traffic.
If G1/G2 are the same and S1/S2 are different, then all multicast traffic for the group except traffic sourced from S2 should be forwarded to the hub. This would require Host1 to to ignore unwanted traffic.
If G1,S1 is different from G2,S2, then all traffic for multicast group G1 from source S1 and all traffic for multicast group G2 except from source S2 should be forwarded to the hub. This would again require both hosts to ignore unwanted traffic.
The reasoning behind this is that this IGMP snooping switch will have separate entries (that contain their respective group memberships along with their include or exclude filters) for both hosts on the interface going towards the hub.
In any case, the hosts should ignore the unwanted multicast, the same as if they were in an environment without IGMP snooping where all multicast is forwarded.
Best Answer
This part of the RFC discusses what should happen to ipv6 multicasts (or any other ethernet multicast mac address) that might share the same mac address with the ipv4 multicast IGMP join received by the switch.
Section 1 makes this clear...