The 'unit of thought' thing is a nod to the Ken Iverson paper on APL that won him the Turing Award ("Notation as a Tool of Thought"), also referenced by Dyalog's tag line "The tool of thought for software solutions"). Variations of that phrase are endemic in the array languages space.
I faced exactly this situation a few years ago - I went with APL as the “OG”, but it probably doesn’t matter that much. Learning k or j once you know APL is much easier. I wrote a bit about this (apl and k)
It makes parsing tricky. But for the programmer it’s rarely an issue, as typically definitions are physically close. Some variants like BQN avoids this ambiguity by imposing a naming scheme (function names upper case, array names lower case or similar).
Yes, it's either an array (if A, B and C are arrays), a function derived via the dyadic operator B, with operands A and C being either arrays or functions, a dyadic function call of the dyadic function B (A and C are arrays), or the sequential monadic application of functions A and B to array C, or a derived function as the tacit fork (A, B and C are functions). Did I miss anything?
Whilst LLMs still perform weakly in APL, the situation is improving at pace, and giving it a “skill” to evaluate code makes a dramatic difference. I gave a conference talk about it recently (video): https://youtu.be/H_wdKeJ8gt4
As to the training set's depth of APL, yes, it's an issue. However, it's worth seeing how well MoonBit[1, 2] works with LLMs, faced with exactly the same problem -- integrating the LLM directly into the parser pipeline.
The learning curve isn’t steep. I’d argue the opposite. K is a tiny, tiny language. Put your mind to it, and you’ll be reading it just fine in a weekend. It’s just different. It’s optimised for its wheelhouse.
<https://xpqz.github.io/learnapl>
<https://xpqz.github.io/cultivations>
<https://xpqz.github.io/kbook>