Math view fields with undefined frontmatter inputs no longer evaluate (regression since 1.4.7)

[Hermegenius]

Please fill out these Check-boxes

• I checked for existing similar issues
• I checked that the plugin is up to date
• The issue persists with all other plugins and themes disabled

Plugin Version

1.4.9

This Issue Occurs on

• Windows
• Linux
• macOS
• Android
• iOS

Debug Info

n/a

Describe the Issue

Plugin version: 1.4.9
Obsidian version: 1.12.7 (Installer 1.12.7)
OS: macOS 15 (Darwin 24.6)

Summary

Since 1.4.7, a VIEW[...][math:...] field that references a frontmatter property which isn't yet defined now renders blank instead of treating the missing input as 0. This appears to be a side-effect of the change in #652 ("Fixed unnecessary updates for dependent view fields during initialization"), which removed the cascading re-evaluation that previously masked the issue.

Minimal repro

Create a new note with this frontmatter:

---
a: 5
total: 0
---

And this body:

VIEW[{a} + {b}][math:total]

b is intentionally not declared in frontmatter.

Expected (≤1.4.6 behaviour): the field renders 5 (b coerced to 0), and total updates to 5.
Actual (1.4.7–1.4.9): the field renders blank, and total is not updated.

Real-world impact

Templates that chain math fields — e.g. line-item totals → subtotal → GST → grand total — break when any single referenced property is missing from the host note's frontmatter. The break cascades: every downstream field also goes blank, even though their own inputs would otherwise resolve. This affects any project that uses meta-bind-embed to pull in a shared math template, since the embedded template's frontmatter defaults aren't inherited by the host note.

Current workaround

Pre-seed every property referenced by every math expression in the host note's frontmatter (payment_fee: 0, gst_storage: 0, etc.). Painful for large existing vaults.

Possible fixes

1. Restore cascade re-evaluation for undefined inputs, with the topological-sort improvement from Dependent computations ordering and stale data #652 to avoid the original churn
2. Coerce undefined frontmatter references to 0 at the math evaluator boundary (mathjs doesn't tolerate undefined inputs)
3. Add a fallback operator to the math syntax (e.g. {field ?? 0} or {field | 0}) so users can opt in defensively
4. At minimum, document the new contract in the math view field reference page so users know to seed defaults

Happy to test any patch against my real templates if useful.

Related: #652

### Steps to Reproduce

n/a

### Expected Behavior

n/a