Thanks, i_s. Daniel chiming in here... for functions and variables, we intentionally stay focused on JSON/YAML-equivalent data because the places where JSON or YAML are used as human-edited interfaces (because of their limitations rather than in spite of them) is the slice of the programming stack that KSON is particularly interested in. If the next Kubernetes/GitHub Actions/dbt/etc wants to reach for a language to be their interface, KSON is interested in providing everything YAML offers and more (AND less: less of the problems associated with YAML)

We have a design for KSON constants that we're looking forward to sharing soon, but they will be constant and KSON will still be JSON/YAML-equivalent. For the places where someone wants more programming power in their config, I'm glad people like the folks behind Pkl and Dhall are serving that use case.