Point take. I would note the point about starting assumptions. Export code is a mark-up macro whose internal use subsequently morphed into action code before export code reverted to an export-only role with ^action()^ as a bridge to effect action code during export.line breaks in templates are literal and should be used with care - generally you can't have a nice layout in both template and output. Way back this mattered little as few looked at (them) HTML code or how it was written. Of course 'HTML' export is now used for all sorts of other tasks and pages are more complex. However, I suspect fixing white-space prettiness wouldn't be a cost-effective enhancement for the app from the vendor's standpoint.
I think nested evaluations, i.e. within var() within ^value()^, is a degree more than envisaged in design, not least as var() post-dates ^value()^ by some way and because ^action()^ is provided for that general purpose. Way back, attribute values were exported by ^get(AttrName)^ and ^getFor(AttrName, Note name)^. When attribute offset references arrived, e.g. $SomeAttr(some note), putting either that or a direct $SomeAttr in a common ^value()^ operator simplified the syntax for learners and provided better export/action alignment of syntax.
All that said, try this as your 'url' template, I think you'll be pleasantly surprised:
The secret is the extra parentheses which causes the output string of ^path^ to be evaluated before a String.replace() operation is attempted. This extra-parentheses approach is worth knowing as a possible syntax shim but doesn't always work - you just won't know until you try. Hopefully comment above as to how export/action code got here will help explain why such seemingly inconsistent outputs occur.
Last thought. If you find a code export or action - whose inputs aren't evaluated and you really need them to be, don't overlook writing into support and suggesting that as a feature request. Long-term Tinderbox users will attest there are lots of such of fixes that often address just one user's pressing problems (I'm certainly one of those). Eastgate do listen to well-explained requests.