Forgetting about the implementation details for a moment...
What behavior would you want to see from m2m with intermediary data?
Can you draft up some examples of how representations should be serialized and deserialized, and how to deal with create and update cases? Can you draft up a failing test case with some expected behavior that isn't current observed?
I think the answer might be that if you need writable m2m-through data, then you need to re-consider the representation you're using.
Taking the example in the docs:
Your Group and Person serializers could include a read-only related field across the 'members' relationship, but they couldn't include a writable related field across the relationship (because there'd be no way of specifying the required extra intermediate data)
Instead you'd want an explicit representation of the Membership (ie a Membership serializer and associated views), and have the Group and Person serializer include a writable related field to the membership_set. (rather than directly to each other)
That feels right to me, and I think is similar behavior to the way that eg. Django's fixture serializers would represent the data(?)
Would def appreciate feedback from you on that.
Also it'd be a really good thing to get documented - dealing with relationships and representations of relationships, especially for writable relationships is tricky stuff.