If you previously couldn’t use Expound because your specs used a custom conformer, try Expound 0.7.2 - it may not be able to give a precise error, but at least it won’t throw a “Cannot convert path” error

Question about evolving specs: I realize the whole idea with specs is "don't change them in breaking ways", so I'm thinking about how to plan for that. If I define a spec with a single definition, then later realize there's another valid representation, so I want to change it to (s/or ....), can that be a non-breaking change to consumers?

I guess if the original definition was one of the options under the s/or it would still validate the same, but the conformed value would change right? I guess generally the conformed value is more likely to be depended-upon by internal code rather than API consumers...

adding additional valid things means old stuff should continue to be valid

I don’t know that we would expect forward-consistent stuff out of conform though