So obviously the lambda-wrapped expression of Interpolation.getvalue can be captured and used later, with possible confusion because of how lexical scope closes over such names. Such power should be used carefully. Tag functions are more like decorators. Decorators can radically modify the behavior of the decorated function. They are still extremly useful however, even if they require care in their design and implementation.
In this particular case, I don’t think it’s idiomatic even if it’s only very limited, because you wouldn’t expose the getvalue in code that uses the tag string.
The more usual way to write it would be for the tag function to immediately call or not getvalue; and if that’s not the case, for the user of the tag string to do something with it (or not). This avoids this whole class of problems.
We want to support deferred evaluation because it allows for writing a tag function like struct_log, which is like a lazy f-string, except that it evaluates its interpolations if rendered, either with __str__ (so works with the standard logging.LogRecord.getMessage) or with a custom formatter to directly support JSON struct logging. See https://github.com/python/peps/pull/3858/#issuecomment-2252818275 which explores this idea. Now instead of developers using f-strings in logging because it’s convenient, they can use an equivalent convenient variant - but it does the right thing.