I bring this up because I believe this relates to the OPs questions about atomicity and queuing related issues.
Not really. Go look closely at the actual code.
While they have a conditional to change the indexes to multi-byte ints, the code will have issues should it ever be done.
i.e. while the indexes will bump to ints when necessary to support larger buffers, the actual code was not written properly to support it.
They even have a comment about it in the header file just above the conditionals that set the type.
Some of what is in that github issue mentioned is that the code didn't always properly mutex critical sections of code to ensure atomicity because due to the way to code/system worked, it didn't have to.
While it is sometimes not necessary and you can get away without doing it due to how the overall system operates, the code can cease to work properly once something changes. And that is what happened when they changed how serial output worked from ISRs.
There are more/other issues than what is discussed in that github issue.
Like available() can return an incorrect value when ints are used.
IMO, the current code should error off and fail to compile if the buffer size requires more than an 8 bit index since the code breaks with larger than a 8 bit index.
Years ago like 10+, the code was even worse.
It always used ints with no protections of any kind.
They used volatile but that that doesn't solve the atomicity issues.
note: it only "worked" back then because they never used buffers large enough to need the other byte so it effectively worked as if it was an 8 bit index
I pointed out the atomicity issues to them and suggested that they change the code to use 8 bit indexes which made the code smaller and faster and suggested it was reasonable since the code wouldn't work with ints anyway>
They didn't want to do it and I'm convinced that they didn't even understand the issues.
It was somewhat similar to the experience I had the first week I used Arduino and found atomicity issue in the digitalWrite() code.
Back then the code didn't ensure that the port update was atomic.
I explained the issue in detail and I even offered the solution, but it took 9 months get the fixed code into the release.
To this day, I still believe Mellis never understood the issue.
He argued that there was no way a foreground task could corrupt a register even if interrupted by an ISR. But that is exactly what happens.
He only relented on adding the fix since the servo library only worked properly with the fix in place.
IMO, the early Arduino.cc development team was very green and simply didn't understand many low level h/w and programming issues.
My suggestion years ago when they were having some Serial buffering issues was to re-write the code to use pointers and a counter rather than indexes.
This would make the code smaller and much faster on the AVR than using indexes.
But I got no support and they instead decided to try to add support for larger buffers and indexes and ended up with the current code that doesn't even work with the larger buffers.
The net result was code that was a bit larger and slower than it could be and still doesn't support larger than 256 byte buffers.
Like I said, sharing data between threads is not easy and often even experienced s/w people can get tripped up and screw it up.
IMO, the HardwareSerial code is great example of this.
--- bill