Hey Ross,
I’m running into something like this as well, with kinematic-type player and enemy objects colliding primarily with tile maps.
In a previous incarnation I was using an actual collision object on the player, set to Kinematic, and using contact_point_response in an expanded implementation of the basic platformer tutorial. I had about 90% of everything working perfectly within a couple of days, being completely new to programming, which I was pretty proud of.
Then I spent about 2.5 weeks struggling to get sloped (just 45 degrees) platforms working, and never was able to manage it consistently. Frustrated, I dumped the whole project and started from scratch.
Now, my player character does not have any collision object attached at all (well, he does, but it’s for enemy interactions, damage and such). He is colliding with the tilemap strictly through code. What I’m doing is probably highly inefficient, unfortunately I don’t know enough about what I’m doing to know…but it has solved ALL of my collision issues, including the “bullet through paper” problem you’re having, as well as allowed me to easily implement specific sloped terrain (we’re only using 45s. Other angles would present more of a challenge…)
It’s basically this:
Each tile in the tilesource is stored in a descriptive table. The tables look kind of like:
solid = 1, 3, 4, 10, 11, etc
left_slope = 2, 5, 6, etc
right_slope = 7, 8, 9, etc
(a more thought out tile sheet would make this a little easier, but whatever 
)
I have a module with conditions set out for what to do in the scenario of each type of tile, divided up into separate x and y movement (basically calling a “move x” function and then a “move y” function).
The player character itself can be given a move instruction, say “move 10 pixels to the right, and 8 pixels down.” These are passed into the appropriate x or y movement module functions as x = 10, y = -8
These functions run a loop for the absolute value of the number passed to them (so, 10 loops for x, and 8 loops for y), and convert the sign to a direction (+1 or -1) internally in the loop.
For each pixel of requested movement (so, each loop) the appropriate checks against the tiles are made, and if movement is not possible, the loop kicks out and returns the total amount of movement possible before collision. These x and y values are returned back to the player script as the final destination for the next frame, so collisions are actually prevented before they happen.
I’m fairly certain this is re-inventing the wheel in a lot of ways, but the bottom line is 3 weeks of fighting against built-in kinematic collision got me nowhere (almost certainly my fault due to lack of experience), and 4 days of building this way got me exactly what I wanted. I’ve dropped 75+ “player” characters into a single screen all moving based on this module, and there has been no measurable slowdown at all. In actual gameplay, there will be at most 15-20 entities existing at one time on screen (the rest spawning and deleting as they move on/off screen) so I don’t really foresee any performance issues here, but who knows.
Anyway, not sure if this type of method would help you, just something I dreamed up one evening at my local and I’m happy so far with how it’s working for my particular project.
-RSL
