Also, I was wondering how you could make use of contiguous memory when a system makes use of sets of different types of components as this seems to be the case for most systems, especially if you slice the components into smaller pieces?
In complex situations where a system requires multiple components to perform it's job, I tend to side on the caching approach. Basically the system uses the notification callback when entities are added, changed, or destroyed to manage an internal list, a list I prefer to call node list. How and when you elect to transfer component data to the node list is entirely dependent on how the system must update in accordance with your game loop. You may need to use a command pattern to delay the update until the system's update loop or it may be safe to immediately update the node list directly.
A render system for example may require a Transform and Renderable. As entities are added, changed, or destroyed the render system maintains a list of RenderNode instances that basically cache the transform and renderable data from the components. The render system's update loop uses the RenderNode list rather than the components themselves as the basis for it's update loop iteration to maximize on cache friendliness.
Nothing says a system must maintain a single node list either. In fact, it really should be a system detail that dictates how many node lists it must maintain in order to efficiently perform it's update phase. Multiple lists are often used to avoid if/else branch statements inside the loop which can be costly on cache friendliness.