Am I right in thinking that the equivalent of ColliderA and ColliderB is as follows:
Yes, although you'd need to cast the CollisionEntry to an EntityCollisionInformation to get its entity, if it is in fact an EntityCollisionInformation. The reason for the abstraction is that it could be colliding with something that isn't an entity, like a StaticMesh, Terrain, InstacedMesh, etc.
However, even some things that are not Entities do have Materials (like StaticMesh, terrain, and InstancedMesh).
Can I set the material for the pair with the latest beta
That approach will change the entity material properties, and in turn re-blend the properties in any pairs associated with the entities. That is not a thread safe procedure, since the pair handling runs in parallel and there could be times when multiple pairs are associated with the same entity.
One better approach would be to use the Material system to define pairwise behaviors before collision pairs are created (using the MaterialManager as explained earlier).
Another approach is to do it the way you did it in v0.14.3. Each pair that cares about materials has a constraint, which contains the blended material properties. Getting at this information is a little tricky at the moment due to the abstractions, but it is theoretically doable. It might be worth waiting on improvements to usability before going this route.
Matrix3x3 makes life difficult with non extension Transform methods:
Here's three ways to deal with this without extension methods:
-The WorldTransform property returns an XNA matrix which can be used with the Vector3.TransformNormal method.
-Matrix3X3 has its own transform methods, though some may be lacking in non-ref parameter overloads at the moment.
-Matrix3X3 has a ToMatrix4X4 static method.
The "fastest" option is to use the Matrix3X3 transform methods, but I wouldn't worry too much about that level of performance optimization when doing game logic.