Checking the repo out at the default path generally simplifies things.

This will checkout the repo in the current dir. I don't see how this is desirable, are we sure about this?

It's desirable for standardisation and because other Actions can make the assumption that they have a checkout of the repo in the expected place.

to make sure I understand: we do ditch this approach for workflows involving several checkouts, right?

and does it mean we need to worry about where we create our database? there's no guarantee that DB_PATH doesn't collide with a directory from the checkout

(I initially thought that the default path would be the name of the repo, similar to the gh repo clone command)

The same $RUNNER_TEMP logic really ought to apply to the other checked out repos - or any directory we'd like to create for that matter. I don't have enough knowledge to have a strong opinion but, on the basis of the workflows I interact with, this new approach is a net regression.

The only difficulty with that is it becomes slightly harder to reference where the repo is, so you'd have to write working-directory: ${{ env.CODEQL_LIB_PATH }} for example.

I'll have to disagree with you on the net regression. The Action is now considerably terser and easier to read in my opinion.

It's fine to disagree - but the workflow is actually more verbose and convoluted: instead of checking out in foo and then creating a bardirectory without worrying, we have to use temporary folders. And the more repos/directories we need to checkout out/create the worse it will get (unless, as you suggest, we are happy with being inconsistent and reverting to a "hope for the best" approach when checking out additional repos). But I admit I don't understand what you meant initially with the expected benefit:

It's desirable for standardisation and because other Actions can make the assumption that they have a checkout of the repo in the expected place.

Did you mean composite Actions? In the case of this workflow the drawbacks jump out but I'm missing the improvements.

(having said that, $RUNNER_TEMP is very convenient - but the inconsistency of the approach remains in my opinion)

Did you mean composite Actions? In the case of this workflow the drawbacks jump out but I'm missing the improvements.

The improvements are most noticeable when using composite Actions, but I think there's a small benefit in standardisation having the repo checked out in the same place — it reduces cognitive load a tiny bit.

Is there a reason why we are downloading codeql instead of using the version in the toolcache?

Is it to ensure we are always running with the latest codeql version?

Yes