The issue was first encountered as a set of jobs that were behaving as if they were Allowing Concurrent Jobs even though they were not set to allow this.

  Even with a single run occurring, starting from an empty workspace (The workspace on the slave was completely wiped) it was creating jobname@2 to run the job.  We cleared this situation up by forcing a restart of the slave.jar process running on the jenkins slave by using Disconnect, confirming that it had shut down, and then reconnected and then backtraced what had actually happened.

Earlier in the week, the Jenkins master had been suddenly restarted while active jobs on some slaves were processing.  These jobs were left in an undetermined state on the slaves (the master decided they had failed) and were the 1 job that the slaves were seeing.  The jenkins master, having no knowledge of these ongoing jobs, would fire off a new job which the slave would treat as a concurrent job.  This state persisted long after the job would have normally finished (Days later).

Repro step:
1) Have one jenkins master, 1 slave.
2) Start long enough job on slave.
3) Restart master, interrupting connectivity.
4) Verify job has failed on master.
5) Run job again.  @2 should occur.

Jenkins version 2.107.1 (had just been upgraded a little before this).