Non-mainstream languages can be a very positive signal for employers I've found.

I've bounced off haskell several times now (I'm probably due another attempt this year, I continue to be convinced the problem is one or more 'aha' moments that I just haven't managed to make click yet).

The "functional core, imperative shell" approach is -fantastic- though and I'm not sure where I picked it up from but a lot of my (especially async/event driven) code looks at least close to that.

It occurs to me that this may be why I've yet to be significantly bothered by function colouring when writing async/await based code in Perl and/or JS, but I'd probably have to give that more thought before I go beyond 'maybe' with that particular idea.

I agree with you. The function coloring "problem" in the Haskell world is basically the distinction between a pure function and an IO function. I put the word "problem" in quotes because it's abundantly clear to any Haskeller that it isn't a problem but rather a beneficial constraint on programming that, sadly, other languages don't enforce in their type systems. The whole point of type systems is to add constraints and prevent you from writing certain hopefully nonsensical programs (if not we might as well go back to untyped lambda calculus which is Turing complete). Haskell just goes further than most languages. When you stick with this kind of constraints, you eventually naturally lead to approaches like "functional core imperative shell" which is an improvement in code quality and clarity.

For a junior programmer, the benefit of such constraints is greater because they do need the compiler to tell them no. The benefit is somewhat reduced for senior programmers because experience leads them to naturally avoid things that a Haskell compiler would have yelled at them for.