Sometimes it is desirable to mark several stage boundaries in a build even though from the perspective of the concurrency semantics they are logically a single stage. This would require a new option to the stage step. Thus

stage 'build'
...
stage name: 'deploy', concurrency: 1
...
stage name: 'test', labelOnly: true
...

would behave exactly like

stage 'build'
...
stage name: 'deployAndTest', concurrency: 1
...

other than the labeling via StageAction. In other words, with labelOnly set, the execution would run this part but then return true to avoid interaction with the concurrency system.

Alternately there could be a block-scoped variant of the step

stageBlock('build') {
  ...
}
stageBlock(name: 'deployAndTest', concurrency: 1) {
  stageBlock('deploy') {
    ...
  }
  stageBlock('test') {
    ...
  }
}

where concurrency would have the same meaning as in stage except that "entering" and "exiting" would refer to the block scope rather than a standalone step. This would overlap somewhat with JENKINS-26107 and might be a good stepping stone to a parallel-aware stage that blocks only within the given branch of various builds. The downside is that blocks must nest, which could be a problem if you wanted finer control over node allocation and so on.