I didn’t notice the experimental sign, thanks for pointing that out.
If an experimental feature is buggy, behaves in unexpected ways, is deprecated, removed, or has breaking interface changes in an update - I think that’s fine. However in my opinion anything exposed to the user should guarantee that the document at least loads or that the user can somehow recover. Buttons can be broken, formulas can be broken, tables can have the wrong data, views, etc, but I should at least by able to modify the doc and attempt to fix the problem.
Maybe this would require a sort of “debug” mode of the document where no formulas are evaluated, no automations run etc, or maybe it would simply be a matter of making all the code paths production ready.
If Coda experimental features have no such guarantee, then in my opinion I think the app should give a much louder warning to the user that the feature should not be used in any production scenario, including when copying docs. There are plenty of docs used as examples here on how to implement things that contain these formulas, it’s quite easy to use something someone else set up that has these formulas without even knowing it. This is actually how I came upon the button formula.