Given the current state of the master branch, a library digesting the return value from quick-check will need to do some acrobatics to tell whether the property threw an exception, since old versions indicate it one way and new versions indicate it differently.
false or user object
user supplied data
map including the exception
This means any 3rd-party library that wants to determine compatibly whether a return map from quick-check represents a success or failure will need to have even more conditionals than before. In particular it will need to (at compile time?) determine if the results/Result protocol exists, and if so examine the :result object on that basis, otherwise using the "is it a Throwable or not?" codepath.
An alternative that only adds new keys instead of changing the meaning of old keys:
Still allow users to return custom impls of the Result protocol, but translate them back into true/false/Throwable for the :result key. Add a new :result-data key that has a :clojure.test.check/passing? nested key, and :clojure.test.check/error as well if applicable.