Your method seems to be sound for finding if there is a collision and with which tiles.
It's worth noting that when the tile and player line up perfectly, it might be unclear which tiles should be considered a collision.
Then, we come to what to do with the information once we have it, which is where I expect the 'glitchy' behaviour stems.
For example, if it's touching 4 tiles (each corner is in adjacent tiles), which seems the most likely scenario, then, at what point, do we consider it "touching" instead of "colliding/overlapping" the very next tile? This would be a design decision.
Although I'm not 100% sure what "holding jump and to the right on a wall to the right of the player" would look like exactly, remember that you "start to jump", you should no longer be able to jump until you land, and that landing should be sure in your design (just on a floor/something below it?). If you wanted to allow what I would call "sliding" (gripping a wall but maybe still falling - at a different rate to normal falling), you should track this as a different state to jumping. i.e. if it is sliding, it's isn't jumping.
I'm guessing this is a form of side-scrolling platformer so my presumptions are based that so if that's not the case, what I have said/am saying may not be correct.
You should consider the "state" (mentioned that briefly above) of the player. Things like isJumping, isSliding, isFalling, isRunning, isIdle are common things to track but you may was to consider using some form of state system (a finite state machine is a common example.
Here's a common explanation of the sort of thing if you don't know what I mean:
https://gameprogrammingpatterns.com/state.html