Please verify

1 track. put a loop on it.
hot but not clipping level.
create and Assign output of loop track to it's own "loop" buss.
Assign loop buss to "master"
 
create new buss called realmaster (outputs to soundcard)
send master buss output to realmaster.
 
check levels.
select mono on realmaster.
 
master clips.
???????????
 
Edit:
Ok, there seems to be some confusion in what I typed.
I think the word Master may be throwing some off.
In this case master is not last in the chain. realmaster is.
(master feeds realmaster).
when I mono realmaster, it affects master. That shouldn't happen.
 
In case you're wondering why do this, ARC is on realmaster.
 
 
 
 

Please re-read Craig.
(master is before realmaster)

Same here. I routed audio, peaking at -0.8dB to Preview buss, which is routed to Master buss. When Master buss is set to mono it is clipping, meter shows 2.2dB. Preview buss is also clipping, peaking at 2.2dB.

Okay, now I understand...the master isn't the "master." I can in fact duplicate what you are experiencing, and I agree it is anomalous. However, I have never experienced it so I was taken aback. But the reason why I haven't experienced it provides the solution.
 
When I want to send from bus to bus, I set the "sending" bus output to "None" and use a send. This is probably force of habit ("I'm sending to a bus, therefore I will use a send to a bus"). If you do this, there are no level changes, upstream or downstream. (Aside from the anomaly you described, I also noticed that the first time I send a bus output to another bus, the second bus has a hotter signal level. If I use a send, there is no issue.)
 
Here's the screen shot that (I believe) sets up your scenario but I'm using sends to get from the Loop bus to the Master bus, and another send to get from the Master bus to the Realmaster bus. Because the Realmaster is set to mono, you'll note that it distorts for the reason I mentioned previously caused by summing stereo to create mono, but all the other bus levels are as expected.
 

 
So the bottom line seems to be...if you're sending from one bus to another, use a send and you won't run into problems. As to why chaining bus outputs to inputs causes issues, I don't know. The only possibility I can think of would be panning law issues that affect bus output pan but not send pan.

brundlefly
I did a quick check and sending the upstream bus to the downstream bus instead of outputting did not eliminate the apparent summing of signals on the upstream bus when the downstream bus is switched to mono.

Any chance the bus output was inadvertently assigned? What you're saying seems to go against what the screen shot shows. As long as I used sends and set outs to "none"...no problems. So now I wonder what's different in your setup compared to what I was doing.

I was wrong about the issue affecting sends. The recent issue with changing focus between buses (you have to hit the top 'row' of the bus) caused me to change the upstream bus to mono instead of the downstream bus. 

I'll remember this ... good info
 

timidi
Sorry Craig. It was my understanding that you work for Gibson/Cakewalk.

 
To clarify, I work with Gibson Brands. For example today I'm finishing a video for KRK on their new V-Series speakers, writing claims for a consumer audio patent I've assigned to Gibson Innovations, and working on the rollouts for the Gibson USA and Gibson Acoustic 2017 guitar lines. I became involved with Cakewalk in a consulting capacity when I switched to SONAR back in 2000, and remain involved now that it's part of Gibson, but I don't make the decisions. A lot of what I do with Cakewalk is on my own time because I believe in where the company is going, and they appreciate my help. Well, at least most of the time...I've also been to known to play the demanding user on occasion .