A couple of things I realise I'm still not clear on. I'm happy to be pointed to a document that explains this in simple terms.
I am not a dev but may can help out with my understanding of things
Is it the case that orders submitted, cancelled or filled during a 10 second
round, cannot be received and displayed by clients as part of the market state
until that block is produced and synced? (as opposed to being broadcast
immediately for all clients to display in the market state?).
Yes .. the client currently only takes confirmed transactions as valid .. though
there is a extra command to schon pending transaction in the network
blockchain_list_pending_transactionsDoes the matching algorithm effectively get applied once every 10 seconds at the
end of each block, when it is produced?
AFAIK that is what is happending .. but the results of the matching algorithm
are not transactions .. in the client they show as 'virtual'. Hence, they are
performed in every client ..
That's why in order to make modifications in the market or the matching require
a hard fork .. so that the clients use the same protocol.
Does it take any account of the time sequence in which orders were submitted
during the 10 second interval of that block? If not, how are equal orders for
that block prioritised for fills?
From what I know, they are not prioitiesed .. First come first serve. Though
this might become a business opportunity. Imagine you have a delegate and
someone wants to make sure that the next block (which you will have to sign)
contains his market transactions .. then you can offer the deal to do so for a
fee. Though I am uncertain as to what shareholders think of it and how long a
delegate could run this business.
Do certain order types get sequenced before others?
sequenced in terms of "ordered by price"?
I don't really know