Actually Continuum add a schedule is associated with a buildDefinition or purge process. Then you need an enable disable previously if it was not associated with a project. I think there are two possible solutions:
1.- When whe updated or add a new build definition or purge process we would check if associated schedule jobs is in queuue (pending to execute) and enable/disable it.
2.- Always (active = true) enqueue 2 jobs, first for buildProcess and second for purge process. They check if there are associated elements to execute process.

What solution do you think is better?

without looking at the code, I'm leaning towards ...

3. Move the code that "checks" somewhere it can be shared between (1) and (2)

As written,
(1) sounds to me like it will add a duplicate check
(2) sounds like you're relying on a side effect of some other process, which will be confusing

Sorry, but I think I have not explained:
Currently only when we enable a schedule we add a job to scheduler(application scheduler- quartz ). Performing the following checks:

if ( isScheduleFromBuildJob( schedule ) )
{
  // A buildDefinition with this schedule
  schedule( schedule, continuum, ContinuumBuildJob.class );
}

if ( isScheduleFromPurgeJob( schedule ) )
{
  // A purge with this schedule
  schedule( schedule, continuum, ContinuumPurgeJob.class );
}

That way if the schedule is not linked to a buildDefinition or purgeConfiguration not work for them. After set a schedule for a buildDefinition/purgeConfiguration we need to update the schedule to add job(s) to application scheduler.

In this way, my options are:
1 - Always add the job (buildDefinition and purgeConfiguration) to the scheduler. Simpler and does not modify the code to buildDefinition and purgeConfiguration
2 - When a store purgeConfiguration / buildDefinition set a schedule we add job to application scheduler. More efficient (the scheduler only contains the jobs to be executed)
3 - Add a single job for application scheduler and its execution launch a thread for builds and other for purge. This solution is similar to the first.

I think i'll go with [2].

After setting a schedule on a purgeConfiguration or buildDefinition, we add another call to schedule the job.

Same goes when unsetting a schedule on purgeConfiguration/buildDefinition, scheduled job should be removed.

Fixed in :

r780709 of branch 1.3.x
r780735 of version 1.4.0