Q1: It kind of depends how you subscribe to messages. NServiceBus was build with the that there are business services (bounded contexts), which cannot share data. However in CQRS you have fat events that contain a lot of data, which are published so that subscribers can store the information in their read model. This read model is than used, for example, in the user interface. Either via a normal UI or via a composite UI (which gathers information from multiple business services). So it depends what you're looking for.
Q2: It is possible to subscribe to multiple events. However there is only one logical publisher of the event. So an event "CustomerWasBilled" cannot come from ComponentA and ComponentB. However you can subscribe to many different events and each publisher can of course have many different subscribers.
[Udi] A given publisher can be scaled out across multiple servers and NServiceBus will handle that for you - no need to subscribe to each machine.
Q3: I would think this is pure administration. If it should stay online and receive messages, queues will fill up. If it should be down/offline permanently and messages aren't processed, then you'd know pretty fast after the component was taken down. But I highly recommend documenting which subscribers and publishers are connected to each other and what happens if you change a message or a component.
[Udi] If it is an orderly shutdown, then it should include the unsubscribe. If it is a crash - ergo temporary, then you detect that with standard monitoring (WMI). In order to protect your queue from filling up, you can define when a message should be discarded using the TimeToBeReceived attribute.
Q4: This is handled in NServiceBus. It stores the subscriptions in a datastore, which can be SQL Server, RavenDB & InMemory. But it also keeps the subscriptions in memory and checks regularly if new subscriptions have been added. Should not be a problem with NServiceBus.
Q5: MSMQ is by itself reliable in nature. Of course if your entire server crashes and all messages were on the HD that fried, that's a problem. If a component is not reachable for a longer amount of days, it depends on SLA if this can happen. You can monitor message count in either incoming queue or error queue. Don't also forget DeadLetterQueue. But NServiceBus lets you also monitor how long it takes for messages to be processed.
When a component is not reachable for a long amount of time (e.g. days) than the business should decide what to do. If it's important messages get processed, introduce clustering, etc.
Hope this helps