This is a good point, but instead of removing the tx I do wonder how it would feel to lean in to it, and make the RYW tx immutable data. If it can be done with still an ergonomic API, you could get one of the benefits of nested transactions, the ability to abandon a subset of operations in the tx, without the IMO confusing semantics that would come from true nesting. The ergonomics might not be there though, since the get would have to return {value, tx} or similar. I could understand going either way. Immutability has served us well though.
I think it’s an important API concept to the end user; it leads them down the path of understanding the power of the ordered keyset. And each use of a subspace is equivalent to an index that doesn’t have to be written. Although, I admit I’ve only used FDB subspace in production code via the Directory layer.
In a new system like Bedrock, I agree that transact is the way. However, {:ok, {:error, _}} as an idiomatic pattern is not ideal.
For the record though, I went a different third way with EctoFDB, since :erlfdb already had an established pattern embracing throws. Instead of transaction or transact, the EctoFDB adapter creates a new Repo.transactional to match :erlfdb.transactional. I did this because I didn’t want EctoFDB to be subjected to the future deprecation and removal of Repo.transaction.
In practice, the transactional throws have served me quite well in production code. But perhaps this is my Judgement of Solomon moment 
.
