[Disclaimer: I've never written a game with an ECS system before, though I've read a bunch about them. So below is acquired second-hand knowledge, not learned first-hand experience.
Take with a glass of water and spoonful of salt. Consume at your own risk] 
Unless you store all types of components in their own respective container (e.g. vector<Position> position_components <-- accessed by entity index/id).
Yes, this is how it's often done. Though because components may move around within the vector as you're adding and removing entities (because not every entity will have every component, and because you may want to occasionally sort components), you may want to do something like:
std::unordered_map<EntityID, ComponentIndices> // or std::vector<ComponentIndices> with 'EntityID' being the index into *this* vector.
struct ComponentIndices
{
int physicsComponentIndex = NoComponent;
int scriptableComponentIndex = 17;
etc...
};
But this would couple back the code again because you'd have to create a new container for each new component that an entity could possibly have.
Yep. You'll also have to write a new data struct and a new logic system for each Component type. It's not hard to type std::vector<RenderComponentDataStruct>.
struct SpecificComponent
{
//...data...
};
class SpecificSystem //Why inherit?
{
public:
void onUpdate();
//other funcs, some system-specific.
private:
std::vector<SpecificComponent> componentData;
};
In some ECS architectures the "entities" are conceptual only, without any actual class. In those flavors of ECS, an 'entity' is just an ID, with all the data in the components and all the logic ran by systems (which may include a scriptable component for more uniquish per-entity custom behavior logic).
Basically, components are the data, systems hold the logic, operate on the data, and own the components. Because some systems depend on other systems (like physics on positions), you can pass one system as a reference to the constructor of dependent systems.
In total, you really shouldn't have too many "systems". A dozen-ish maybe.
But how would I go about making sure only one camera can be active at a time (without making use of a global state)?
What if you want more than one camera active at a time? Maybe you want to support split screen, or maybe you want to, for example, show in the upper-left corner of the screen a door opening up elsewhere in the level when you step on a switch.
Instead of thinking of cameras as "active" or "inactive", I'd just give cameras IDs (if they are entities, use their entityID), and assign your screen a camera.
For example:
struct Screen
{
Rect region; //What region of the game window to render into.
CameraID camera; //What camera to use.
};
void World::Render(const Screen &screen);
Though I don't know if I'd actually make the camera an entity or not. Not everything needs to be forced into components.
It seems like a good idea to use separate rendering systems (e.g. SpriteRenderer, ShapeRenderer, TilemapRenderer) but how do I take care of things like sorting (depth, shader, texture) and batching when these systems are completely decoupled?
You can have those "renderers" generate the drawcalls, and then pass those drawcalls to the real renderer that culls them, sorts them, and then draws them all.
In my code (which isn't an ECS), I call these "batches" - LineBatch, QuadBatch (for sprites, tiles, etc...). Instead of a SpriteRenderer, I create a QuadBatch, fill it with sprites, and then render it.
Basically, the batches are for code-convenience/code-clarity in creating the drawcalls, so they are built on top of the regular renderer. You mentioned different "rendering systems", which is confusing because "systems" mean something specific in a ECS system. You don't want multiple different rendering systems in the ECS sense of the word, but you can certainly have convenience classes or convenience functions that help you generate data for the renderer.
In fact, your components should be at a higher level of abstraction than your renderer anyway (though you may still have a RenderingSystem depending on your design), because not everything you'll draw will come from components. You don't have to (and probably shouldn't) cram your HUD or other GUI stuff into your ECS system, for example.
ECS is a useful paradigm for parts of your architecture, but not your entire architecture. Different paradigms and patterns fit the nature of different problems, and games have multiple problems that are best tackled through the lens of different paradigms. There is no "one solution fits every problem", and because games are complex things with many disparate challenges, ECS doesn't solve every game-related problem perfectly; it solves some of the problems really well, and others poorly, so make it "a" tool in your toolbox, not "the" tool.
