I'm not sure this is the direction we want to go in. This would be different than job arrays. When you requeue a job array, you requeue all the jobs in the array(including all in state X). If we are considering using job sets to replace job arrays in the future, this would make the two designs incompatible.
If we keep all the jobs like the design currently states, I think we should accept jobs to the set after the set is running. It'll likely be deleted, but if the job set is requeued, it would become a viable job.
There is something else to think about when adding jobs in a jobset to the calendar. If we add more than one, we are making our calendar less accurate. We know only one of the jobs in the jobset will be run. By adding them all to the calendar, we take up space and push other calendared jobs out later in time. There is no real good answer to this issue. Just choosing the first one is probably the best answer. It's the most deserving job of the set, so saving resources to get it to start running is good. We're still not sure it is the one which will eventually run though. I think this is a better answer than adding them all though.
If you reject a request for requesting a non-job leader, I'd make it clear what you are doing. Say that the request is invalid because job is part of jobset
If we accept it and do the right thing then we're basically giving a job set many names (every job in the set). We'd have to do this for all the commands as well. If the user submitted to jobset and is part of set and we added it, the user would be confused if they couldn't act upon job set in the future.
One more thing to think about. Do we want to consider a job in multiple job sets in the future. If we do, I think we want to reject the request now.