We are done for now (until we get an apt / yum repository) - the version number is 2021.09.0+351.pro6 and the package will be written as 2021.09.0-351.pro6. We will maintain this convention going forwards.
Moreover, you will notice that all of our products are adopting similar conventions here, although how build metadata is handled varies slightly by product. We are shooting for consistency as much as we can 
The 351 build number is for the open source side of our repository. The pro6 suffix is the 6th build of the "pro" line. In the past, both build numbers were present, but ambiguous. We decided on adding the "pro" piece to make it clear that that is the "pro" build number, and that this is a pro package.
In the open source builds, you can see that we do just have the 351 component: Download RStudio Server - RStudio
That said, our product is versioned as 2021.09.0. The build numbers should have little consequence to users, as we will no longer be releasing multiple versions with different build numbers.
In order to be compatible with semantic versioning (characters after a dot or dash are not interpreted properly) and work with the different packaging paradigms (.deb, .rpm, etc.), a plus sign was required. In fact, this is defined in semver:
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.
I hope that clears things up! If there's anything we can all take away from this - it is that the old adage that "there are only two things hard about programming" should be three:
- naming things
- cache invalidation
- versioning
- and off-by-one errors