Address some CAP-0065 feedback (#1640)

core/cap-0065.md

@@ -48,11 +48,19 @@ The API between stellar-core and the soroban host is modified to allow the modul
 
 When stellar-core starts up, it parses, validates and translates all WASM modules (a `ContractCodeEntry` ledger entry) in the live bucketlist and stores them in a single in-memory, reusable module cache.
 
-When a `ContractCodeEntry` is uploaded or restored from the hot archive bucketlist, it is added to the reusable module cache.
+When a `ContractCodeEntry` is uploaded or restored from the hot archive bucketlist, it is added to the reusable module cache _after_ stellar core finishes processing all transactions in the ledger containing the upload or restore operations.
 
-When a `ContractCodeEntry` is evicted from the live bucketlist to the hot archive bucketlist, it is removed from the reusable module cache.
+When a `ContractCodeEntry` is evicted from the live bucketlist to the hot archive bucketlist, it is removed from the reusable module cache, again _after_ all transactions in the associated ledger is processed.
 
-No other changes occur. Users should observe no behavioural differences, just lower fees due to the elimination of parsing, validation and translation costs during transaction execution. The "cache" will have a 100% hit rate since transactions can only invoke contracts currently in the live bucketlist. The cache therefore no longer behaves like a cache so much as simply a ready-to-run representation of the content of the live bucketlist.
+No other changes to the protocol occur. Users should observe no behavioural differences, just lower fees due to the elimination of parsing, validation and translation costs during transaction execution. The "cache" will have a 100% hit rate since transactions can only invoke contracts currently in the live bucketlist. The cache therefore no longer behaves like a cache so much as simply a ready-to-run representation of the content of the live bucketlist.
+
+### Fees and edge cases
+
+Uploads will still be charged the cost of a full parse of the contract, using the coarse worst-case cost model reserved for unknown contracts. This is the same cost model used during uploads before this CAP.
+
+Executing a contract _in the same ledger_ that the contract is first uploaded will incur a full parse/validate/translate cost just before the execution, using the refined cost model of _known_ contracts that was introduced in [CAP-0054](./cap-0054.md). In other words the low cost instantiation that is new to this CAP (omitting the parse/validate/translate costs) will _only_ apply to ledgers _after_ the ledger in which a contract is uploaded.
+
+Evictions are performed before uploads or restorations, at the end of ledger close. In other words if the same entry is both evicted and uploaded in a single ledger, the state of the module cache after the ledger will contain the entry.
 
 ### XDR changes
 None.