With no functional gain other than readability, I'm in support of the idea since I feel Ash is lacking in its readability.
With downward compatability in mind, I'm in support of the Perl/PHP multiline syntax used in your first snippet:
The above currently errors so there would be no downward compatability issues with currently functioning scripts since no currently existing scripts would have been able to utilize the syntax for anything that doesn't error.
world");//No downward compatability issues
So if we implemented it as a syntax addition to Ash, the change would be rather seamless.
Regarding your second snippet's C-style concatenation idea for wrapping long lines without the inserting a new line character,
I don't think it would help readability whatsoever. If anything, I think it could potentially make debugging Ash syntax errors harder such as a missing comma between arguments. If speed is the concern here to avoid unnecessary concatenations, that's already possible with one long line. I see no reason why Ash scripts can't be written with both a readable well-commented development version as well as an optimized "minimalistic" production version.
Regarding your second snippet's C-style backslash idea, as far as I can tell, it would become redundant if we went with the first snippet's idea. But if we didn't go with the first snippet's syntax, backslashing could be useful. But honestly, I find the syntax very ugly and hard to manage. Imagine 100 lines of CCS and having to append a backslash on each of them. Not only does it make the CSS harder to read, when you need to add a new rule to the CSS, you gotta remember to add a backslash which is very easy to forgot, resulting in more debugging.
Regarding template literals, I love them in PHP, but even in PHP I find printf and sprintf easier to maintain when you're working with a lot of variables.
If we simply added Perl-style multi-line string support, then this becomes a reality:
Native printf/sprintf support would also be nice, but it might conflict with some already existing scripts. But as long as you define the function natively with a signature/prototype in such a way that there's no way we can conflict with it, then that would make life as an ash scripter a hella lot easier.