The next OP release (1.12 - "The Motion Update") includes 2 big bits of functionality: (1) blocks which can move other blocks (like a Micecraft piston) and (2) sub-block collision (stairs, slabs, etc). The core of the support for (1) is now in-place although some interactive testing and additional details will need to be added closer to release.

The core mechanic required that a sort of "transactional block mutation" concept be created, but I think that the approach used makes sense (active mutations against blocks involved in a move will stop any of it from happening - this uses a pessimistic strategy where conflicts result in nobody making progress, but that seems reasonable since conflicts have no natural resolution). This means that blocks which contain things like inventories, etc, can actually be moved, just as long as they aren't logic-sensitive. This restriction will likely be further parameterized in the future but creates a simple rule for the next release.

The next plan for sub-block collision initially seemed very complicated but the current plan shouldn't be that bad, so long as the cases which care about it don't become some protracted game of whack-a-mole. To keep it simple, every block will either be solid, have a non-solid viscosity, or will have "sub-block" behaviour. The sub-block behaviour, which can account for things like facing direction but also active logic state (for doors) will mean that a block becomes a 4x4x4 sub-block grid, represented by a solid/non-solid 64-bit vector. The normal collision logic will need to be modified to account for this, switching to a 4x zoom when computing intersections, and then just handling sub-blocks as a different viscosity look-up mechanism under the same logic. I just hope that this logic doesn't become too complicated or that there aren't too many places which need to be modified to account for this (I think that there are just 2, but I worry that some may be hidden).

Once the new collision logic is in-place, some change for movement will make sense to allow a "step up" so that climbing stairs can be done without jumping. I actually noticed that this should fit within the existing movement design, long ago, so hopefully that works as elegantly as my initial assumption (I know that there is at least one non-trivial case I need to consider, but that should be not a big deal).

I also noticed a bug introduced into the storage conversion logic in the last release, but it isn't something which happens often (hence why it wasn't found), and has already been fixed for the next release.

I will post more updates as they become relevant,
Jeff.