While I agree, those are all built-in functions. I suppose that's why there's the doc-on-highlight feature. I'd need to wrap them if I wanted just to rename them.

No, the original function names are better than your replacements, because they accurately describe what the functions will actually do instead of assuming they know what the user wants. Your names imply non-trivial differences in the way the functions work. These are library functions, so their names must be carefully chosen to imply only what the contract of the actual method supports. In particular:

    Executors.instantiateThreadManager()

You lose information about the thread count (single thread). Also, a nitpick I know, but in Java new means instantiate, so just say new and save typing. Also, an executor is not guaranteed to be a thread manager in any meaningful sense. It is only guaranteed to be an Executor.

    exec.queueForAsyncExecution()

This may not actually be async. 9/10 it is, but the interface does not guarantee async, just a de-coupling from queuing and execution.

    exec.executeQueued()

This misses the fact that calling shutdown will deny future tasks from being queued after it is called.

This is actually a great example of why function names are not a sufficient replacement for appropriate comments.

Comments like "add one to index" are a symptom of laziness, not of commenting about the wrong thing. As an example, here is some of my actual code:

    /* Prompt for scheduler. */
    if (!flag_scheduler_selected && !flag_no_prompts) {
        option_scheduler = prompt_scheduler();
    }

The purpose of the comment is not to tell you what it is doing or why I'm doing it. The comment is there to tell you that what I am doing now has nothing to do with what came before. It signals a mental context switch. Without the comment, you wouldn't be able to easily scan the code and see where different things are happening.