Register design question

[Charles Day]

I have a question about the register design. I've looked through the .h
files are this doesn't seem to be addressed.

Background: The register has a whole bunch of different cells. For example
there is a cell for a posting date, one for a check number, one for an
account, and so on. Depending which type of row you are currently on, only
some of these cells are contained in the current cursor. For example, in
transaction journal mode if you are on a split row then the account cell is
in the current cursor but the posting date is not (instead it is part of a
separate cursor for the transaction row).

At any time it is possible to look up the value of the posting date cell,
but if you are currently sitting on a split row, then the posting date cell
contains the posting date of the last transaction row visited, which *might*
not have been the same transaction that your current split belongs to.

Have I lost you yet? Because I'm wondering if this is the way it is supposed
to be.

There would seem to be two possibilities: 1. You are not supposed to assume
that cells outside the current cursor are valid. So when you are on a split
row, all cells that are not in the split cursor, such as transaction-level
cells like the posting date, should not be trusted. 2. All cells are
supposed to be up-to-date, even if they are not part of the current cursor.
This would mean that when the user tries to move from a split row in
transaction A to a split row in transaction B, you'd have to first visit
(programmatically) the cursor of transaction B to make sure all the
transaction-related cells are up-to-date, then move on to the split the user
wanted.
Does anyone know which is correct? Most of the code that looks up cell
values seems to either observe #1 or works either way, but there is one spot
involved in bug 567709 that definitely assumes #2.

Cheers,
Charles