@bogwar Thanks for all the work on this. Seeing it in print now, a couple of things occurred to me as possible.
implicit schema vs explicit schema - the idea that each schema should predefined what will be in a tx block gives me pause as it is very hard to predict all inevitability. Something along the lines of saying that field names with a particular prefix or pattern must be in the hash may be a bit more pliable ling term and still accomplish the same thing.
For example, “7_key_to” and “7_key_from”. If later someone comes along and thinks it is important for there to be a field like “7_key_seed” that is used in an nft random modification then that can make sure it is included in a hash by adding the “_key_”. Any items without a number_key can be safely ignored.
Call data- I really like the distinction and insistence that this is included. Might it warrant its own section with call parameters? I had taken atab at capturing a call and even associated important metadata in ICRC-133 Generic Input Capture and State Change - Extends ICRC3 . It may have some overlap. There may be some issues down the road as well since some things like icrc7’s mint block may have megabytes of data included, which isn’t great for a log(in that case 133 offers to hash the args.)
I’m not wild about ledgers being abandoned to the wolves and icrc-1 ledgers with the current block types that are actually not compliant icrc-3 get a pass, but certainly nice to get everyone on the same page going forward.