Certainly. However I didn't think I was changing the default behavior for Binding.getProperty of throwing a MissingPropertyException, only adding the option to change the behavior to be used specifically by those that need it. But perhaps your saying just having the option at that low a level doesn't sit right with you, and I'll of course defer to your expertise.
It looks a little trickier to move the behavior up to Script however. SimpleTemplateEngine.createTemplate(...) defers Script creation first to InvokerHelper.createScript(...) via groovyShell.parse(...). Then when the user calls .make(...).toString() on the returned SimpleTemplateEngine$SimpleTemplate another Script instance is created using the class from the first, via InvokerHelper.createScript(...) directly this time. I'm sure there's a reason for all that, but not being familiar with it I'm not clear on where I should try to hook a configurable Script instance or class into the mix? I'm also not sure how I'd work that into GStringTemplateEngine either, as it doesn't appear to use Script directly at all. With Binding it appeared straightforward to hook into both.
I'm all for offering the end user a choice for how to handle missing properties. Perhaps a better approach, for Script or Binding, would be to introduce a "MissingPropertyHandler". The default one would throw MissingPropertyException, but the user could set others for "", "null", null, another constant, or even something dynamic.
Just let me know how you think I might proceed and I'll give it another go.