@rendle.dev , I believe you should add some APL to the next version of BSLang

x: "but.... what do I choose?"
Nick: [ Reply what you think @nick-tune.me would respond]

x: "I want this property"
Nick: "then do this"
x: "I want that property"
Nick: "then do that"
x: "but if I do this,I can't have that"
Nick: "yes they are mutually exclusive"
x: "and if I do that, I can't have this"
Nick: "yes, they are mutually exclusive"
Nick: "and the statement is commutative"

dual write problem ?
dual write problem ?

additionally , a rise of serious security issues

Stack.Pop()

I'd argue you should event source it :
A good article on the subject .
blog.bittacklr.be/the-workflow...

it existed in the 90s , though only a bandwidth problem back then
( and DNS of course)
paper shipping paper with text on it was way better bandwidth back then .

There is also another POV :
- Upcasting
->when you want your code to work , internally , exclusively on the new version

- Weak Schema
-> for the consumers to be able to keep their old code
( and I'd not make new field optional , I'd add with sane defaults in the producer)

and when not possible: e.g: projecting to 1000s of file
- 1 checkpoint file to restart, can be behind: useful when restarting the projection host
each file contains the last checkpoint it was processed with , so that the projection can ignore in it receives previous data

Worse is the assumption that there is no process because some do not see the expected tools.
The process is not the tool .
The tool helps to accomplish task in the process