I wasn't planning on getting sophisticated enough to rotate solidity, at least not for tiles. The idea would be, each tile on the map, even if it's doing real-time rotation to draw its graphics, will still have a set solidity function that will be pre-processed for optimal performance. Each tile will still be associated with some pre-defined shape (now you can make your own shapes, though). And when sprites are interacting with the map, they will just have square solidity regions (similar to GameDev 1.x) but now you will be able to make that
region smaller than the sprite graphic and offset it so it's not in the top-left corner. (This is accomplished by properly defining the frameset transformations for the frames that compose the sprite, and then defining the width and height of the sprite solidity when creating a new sprite state.)
As far as sprite collisions with other sprites, you have a valid concern. I haven't solidified the design of how sprite collisions with other sprites will work yet. However, you should know that my real-time rotation support will all be based on frameset frames that define the transformation. I'm not currently planning to intrinsically support the ability to define an arbitrary rotation at runtime. If you want to draw a sprite at a particular rotation, I'm thinking that you will have to define a frame (in a frameset) that rotates a graphic cell to a particular rotation value, then reference that frame from the sprite state. I hope this is acceptable. There should eventually be wizards to automatically help generate these rotations etc. Yes, that still means you have to define all your rotations ahead of time, but the advantage is that you don't need to store the rotated versions, and then you can define the properties of each rotation separately (define a different bounding/solidity box). I'm not planning on supporting bounding boxes that don't align with the X and Y axes. But I might support pixel-based collision masks, which I would have to pre-calculate for every frame of every sprite (alpha > 127 = solid, alpha <=127 = empty?). That means each rotated frame would have its own pre-calculated collision mask, stored simply as an array of bits, which should work much faster than my collision detection in GameDev 1.x. Not sure if I'll take that on in this release.
Some of this isn't set in stone either, though. I think the code is open-ended enough that you could relatively easily implement a user-defined property on a sprite that determines its rotation, and change the common sprite code (which is saved as part of the project so you don't have to work with a customized version of SGDK2 to do this!) to process that user-defined property as a rotation that should be applied before drawing (just change the Draw function that draws the sprite). Of course that still leaves the exercise of the bounding box to the reader. But at least some of the flexibility is there.