Interesting question!

Only indirectly, by transforming your %PrimeNumberCollectorsCard{}-struct into something that has an identical structure for equivalent datatypes.

Let me first show you a simple ‘solution’ that directly uses MapSet.difference, but still has a problem:

def prime_card_identity(card = %PrimeNumberCollectorsCard{}) do
  {card.edition, card.prime}
end

def missing_cards(your_collection = %MapSet{}, full_collection = %MapSet{}) do
  your_collection_identities = MapSet.new(your_collection, &prime_card_identity/1)
  full_collection_identities = MapSet.new(full_collection, &prime_card_identity/1)
  MapSet.difference(your_collection_identities, full_collection_identities)
end

This works mostly, but the return result of missing_cards/2 will be a MapSet containing identity-tuples like{1, 2}. You could write a function to recover the original %PrimeNumberCollectorsCard{}-struct, by constructing one (but then you do not have the fields that are missing from the identity representation), or by looking it up again in the database (which is slow since we basically discard results from an earlier query, and now do at least one (but possibly N) new queries).

Instead of using MapSet.difference, we might be able to use a Map directly: In a map, the keys have to be unique, but under each key we can track any value we like (whose uniqueness is not enforced by the map). This would make our code look as follows:

def missing_cards(your_collection = %MapSet{}, full_collection = %MapSet{}) do
  your_collection_keys = Enum.map(your_collection, &prime_card_identity)
  
  full_collection
  |> Map.new(&({prime_card_identity(&1), &1}))
  |> Map.drop(your_collection_keys)
  |> Map.values
  |> MapSet.new
end

Interestingly, MapSet.difference/2 is implemented much in the same way under the hood.

No worries: This has nothing to do with OOP vs functional programming.
Instead, MapSet was built in the way it is for (a) simplicity and (b) low memory (both RAM and when serialized on disk) usage. The trade-off has been made that elements in a MapSet are always expected to be unique according to their structural equality, see Erlang term comparisons’ “exactly equal to”.

When adding a separate ‘element’ vs ‘element identity’ representation, you’ll have to either:

• keep track of them separately in the datastructure, thus using more memory.
• recalculate the identity all the time when manipulating the set, thus being significantly slower (with operations going from amortized constant time or logarithmic time to linear time).

And with the alternate approach of using a ‘comparer’ function and storing the elements internally in a binary tree, we still reduce amortized constant running time to logarithmic running time, as well as needing n * log n amount of space for the tree.

Neither of these approaches are bad, but they make different trade-offs than the ones made for MapSet.
I definitely do think that there is a place for sets that allow either custom identities or a custom comparer function. Hopefully, this will be filled by a library at some point, because re-inventing this wheel for every project definitely is not fun and not productive.

If you are wondering by the way, the difference between these two approaches (a comparer function vs custom identities) is similar to the difference between Enum.sort/2 and Enum.sort_by/2.