Found while running stripTies on Schoenberg op19/6, measure 8, but minimal example here:

eighth = note.Note(quarterLength=0.5)
tripletEighth = note.Note(quarterLength=(1/3))
eighth.tie = tie.Tie(type="start")
tripletEighth.tie = tie.Tie(type="stop")

s = stream.Stream()
s.append((eighth, tripletEighth))
s.makeMeasures(inPlace=True)
s.stripTies(inPlace=True)

singleNote = s.flat.notes[0]
(singleNote.quarterLength, singleNote.duration.type, singleNote.duration.tuplets[0])

(Fraction(5, 6), 'quarter', <music21.duration.Tuplet 6/5/32nd>)

Math checks out, but neither a musicxml export nor a roundtrip back using makeTies will do anything with the 6-in-the-space-of-5 32nds tuplet, which makes for difficult to read output (or lost information if the musicxml importer decides to drop the tuplet bracket on the note altogether).

I'm suggesting quarterConversion could try harder to come up with a complex type. In this instance it would involve storing five components of 16th notes, then a 3/2/16th tuplet applied to the whole thing. m21ToXml splits on components when exporting, so I would expect a clean export if we had a complex type. makeTies could also do something similar to ensure a roundtrip after stripTies came back the same.

I looked at how the duration algorithm works now, and for an input of 5/6 QL it finds 1/2 QL first, then looks at the remainder (1/3 QL) to see if it could be added as a second component, but by design does not allow tuplets. But we could find the LCM and make sure's it under an acceptable ceiling.