Conflict when transacting non-unique values for entities resolved by composite tuples

In the context of a single transaction, should we be able to transact two different values of an attribute for the same entity whose ID is resolved by a composite tuple?

(d/transact conn
            {:tx-data [
                       ; New or Upserted Entity A
                        :feature/name   "abc123"           ; not unique
                        :dict/lemma     "starship"
                        :dict/pos       :noun
                        ; tuple constraint unique by identity
                        :dict/pos+lemma [:noun "starship"]

                        ; The only change from Entity A is to a non-unique attribute, which presumably resolves
                        ; to the same entity as Entity A but with a "newer" :feature/name value
                        :feature/name   "abc789"           ; ✖ the only change
                        :dict/lemma     "starship"         ; ✓
                        :dict/pos       :noun              ; ✓
                        :dict/pos+lemma [:noun "starship"] ; ✓

Execution error (ExceptionInfo) at datomic.client.api.async/ares (async.clj:58).
Two datoms in the same transaction conflict

The exception occurs when :feature/name, a non-unique attribute with no relation to the composite tuple, has two different values in the same transaction.

Rather than an exception, I would have expected Entity [:dict/pos+lemma [:noun "starship"]] to now have a :feature/name value of abc789

A single transaction is atomic. That is, transactions don’t have any internal order, so the notion that “abc789” is ‘newer’ than the other value asserted in the same transaction is incorrect.
As you found, you can’t assert two different values for the same EA pair in a single transaction, independent of whether the transaction involves tuples or not.