Yes, we will have to support this. As a workaround you could implement your own BaseKit.selectIdentifierAction, which
could do something smarter depending on where the caret is in a document.

I'm just wandering if this could be lexer-based. Idea: instead of asking modules to supply Acceptor implementation the
BK.selectIA would simply drill down through the TokenHierarchy to the bottom level token and selected it. For the
purpose of BK.selectIA an identifier is pretty much the same as a token. Additionally, the action could limit the
selection by whitespace to make it work reasonably well in comments, javadoc, etc. Languages that need something special
could simply reimplement the action on their own.

Do you think this could work or am I missing something important?

Yes, I was thinking about it too but I'm a bit skeptical since the tokens would likely need to publish some additional
information if we want to retain the current functionality. There are two acceptors: IDENTIFIER_ACCEPTOR and
WHITESPACE_ACCEPTOR (and the rest of all the other characters). So the Ctrl+Left/Right action jumps to boundaries of
chunks of characters of the three groups. With tokens we would either have to categorize the tokens in a similar way or
jump over token boundaries but then e.g. jumping beyond ';' with Ctrl+Right

    list.add(new Integer(5|));

would take 3 presses instead of the current single one.

Instead of single-char-acceptor I would rather pass something like

    wordBoundary(CharSequence text, int startOffset, boolean backwardSearch);

For embeddings the text could correspond to the nested language section. If not found we could return -1 instead of
0/text.length() (not sure whether we would like to always have a word boundary at an embedded section boundary).

any plans here?

Is it now possible to add identifiers to languages? I'm struggling a lot with SCSS, it's not selecting the text I want when double clicking, but it's working all good on CSS.