I've had some experience with this area and asked similar questions to Salesforce.

"For b) my guess would be there is no impact on custom object count as its a managed package."

Yes providing your package has Aloha status (which requires Security Review to be passed).

"For a) I'm not so sure, is 10MB a hard limit for the org and is set 'high' as it is expected this limit will not be hit across all managed packages and customers customer settings combined."

Public and Private custom settings also share this regardless. My notes from the last time I discussed this with Salesforce indicate this is scoped by namespace/package. Though I note the documentation does not reflect this, I would raise a support case to confirm this.

"What happens if there is 3MB of custom settings data and only 1 user in the org (so only 1MB of custom settings data is allowed)?"

When you reach the limit you will receive a run time exception from Apex code and a mesage in the UI if creating manually. According to my reading of the docs one (licensed) user will only result in 1MB of maximum cache for settings. Hence the 'lesser' highlighted in bold in the docs.

The total amount of cached data allowed for your organization is the lesser of these two values: 10 MB 1 MB multiplied by the number of full-featured user licenses in your organization For example, if your organization has three full licenses, you have 3 MB of custom setting storage. If your organization has six full licenses, you have 10 MB of storage.

Custom Setting Limits.

For certified managed packages, each namespace gets its own set of limits. Excepted from this separation, however, is CPU Time. Packages which are not certified share all per-transaction governors with the local namespace.

From Execution Governors and Limits:

Per-Transaction Certified Managed Package Limits

Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Salesforce AppExchange, and have unique namespaces.

Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.

There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn't have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.

Note
These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org's custom code.