There is also a deftype that does this (bitset), but that shouldn't matter for now; @puredanger has suggested on Clojure Slack shouldn't do that either, though.

I have filed an issue with Clojure as well, since I'm not entirely sure who eventually resolves this and how: http://dev.clojure.org/jira/browse/CLJ-2020

__meta and __extmap have always been off limits and marked in the docstring - I would take the __ prefix there to imply that this is a naming convention for internal stuff and suggest that datascript's use of __hash and __hasheq was treading on the obvious future field names for a record caching its hash values. I would certainly prefer datascript to switch to a different convention (or maybe remove it entirely if the new behavior satisfies the same need).

Removing it entirely would be a performance regression on <1.9.0, right? What would be the impact of just renaming it?

I have declined the Clojure ticket - I do not believe it should have been considered valid to modify a record's hash semantics - those are controlled by the language (and should match those of a map).

If you want control over hashing, you should use a deftype, where it's perfectly ok to extend IHashEq. I would say even there that using a __-prefixed field name is inadvisable, but is ok.

I cannot answer the question of performance if this code is modified. It may be necessary to use a deftype for those records prior to 1.9.

This issue is a blocker for my work on Arachne; I am using spec heavily and will have to temporarily disable DataScript support until it works with Clojure 1.9.

Whoa, awesome! thanks @tonsky!

Badass, thanks!