[SalesForce] Batch Apex Governor Limit and Managed Package

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.

Yes, the documentation in question is incorrect. You can prove that the Limits class does not conform to what is written therein fairly easily:

public class Demo implements Queueable
{
    public void execute(QueueableContext context)
    {
        system.assertEquals(1, Limits.getLimitQueueableJobs());
    }
    @future
    public static void doStuff()
    {
        system.assertEquals(1, Limits.getLimitQueueableJobs());
    }
}

Proving it for batches is a fairly straightforward alteration of the above.

Some pieces of the documentation, however, do touch on this point in a way that properly explains the governor limits involved. They are somewhat lacking in clarity, but you can only execute one job from within a job. Here's one such example:

Chaining Jobs

If you need to run a job after some other processing is done first by another job, you can chain queueable jobs. To chain a job to another job, submit the second job from the execute() method of your queueable class. You can add only one job from an executing job, which means that only one child job can exist for each parent job. For example, if you have a second class called SecondJob that implements the Queueable interface, you can add this class to the queue in the execute() method as follows:

public class AsyncExecutionExample implements Queueable {
    public void execute(QueueableContext context) {
        // Your processing logic here       

        // Chain this job to next job by submitting the next job
        System.enqueueJob(new SecondJob());
    }
}

Also from the same document:

When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported.