It is probably possible to coerce our collision system to handle this with some special handling in the slope sprites if you set those sprites to "overlap" (if a collision is detected there, move your sprite to the correct location based on your own logic), but in general this kind of thing falls into the "Not a good match for: Games that require polygons for collision detection." category of our sprite collision detection system.
(now I'll probably keep thinking about this... if I have time to come up with an example implementation I'll be sure to post it here!)
A bit of an old topic, but I'm also on a platform game with slopes and this is the solution I've come so far:
Implemented my own tilemapping, mainly because some tiles are flipped.
When movement is requested from one sprite, a ray is launched. The first non blank tile hitting the ray, it will be the colliding tile.
From the first colliding point on the tile, to the last colliding point, find the first non transparent pixel.
The colliding point will be one your sprite will be laid on.
Tested on the device and, despite some fine tuning on the algorithm is required, looks cool. However, not sure how this will behave when multiple sprites are on the drawing area.
Another solution I have in mind but didn't test: Implement invisible rails over the floor tiles, so:
Your character could move freely all over the map, and detecting collisions with default Playdate way of doing it.
When your character is on a rail, if it moves left, it will move on the direction the rail is pointing to. In flat floors, direction is either left or right. In slopes, up-right, down-right, up-left and down-left.
This one should be quite performant, but it wil be needed that you add extra information on the tilemap.