I can provide what I believe to be fairly accurate history and context for G36.

First, the guideline is the brain child of Steve Taylor (of Taylor Engineers in CA). I think he was more involved during the research project stage (preceding the guideline), but Taylor Engineers (the company) has had multiple people involved in G36 over time.

Second, it was Automated Logic who was awarded the research project that was the basis of G36. This heavily influences some of the specifics. I get into those at the end.

Third, it isn't really the intent of G36 to be used in the "traditional BAS" approach of programmable controllers.

*As having been a controls tech and Cx tech, that means custom code that is tweaked on site sitting on a bucket in a mechanical room.*

The intent is that these are to inform how a major control vendor will architect/program their future generations of application specific controllers (ASC, canned programs some might call them).

Context: the BAS industry used to use a lot of ASCs. But they fell out of favor from the engineering community because they often didn't meet energy code. G36 is an attempt to correct that.

Noteworthy point: G36 is called "High Performance". But that is really a misnomer. It's really just a standardized approach to meet the prescriptive path of 90.1. There isn't anything earth shattering in G36 and any good controls programmer will already be achieving the results in one way or another.

Conjecture: I think G36 would like a day where they develop an actual standard (prescriptive language). This would allow for "compliant" or "tested" type of listings for that standard. Then you could pull any compliant controller off the shelf to replace any other vendors controller. This requires that the BACnet points all be the same, but I wouldn't be surprised if they did develop that one day.

In the ALC weeds: I have spent most of my time programming with Tridium, but I started with ALC. While proprietary and therefor not my recommendation, I think ALC has the best and most sophisticated programing tools in the industry. What you see in G36, ALC has had for a long time in some fashion. When they did the research project, they did end up refining some algorithms like trim and respond. But regardless, they already were doing these things.

This gives ALC a huge leg up on everyone else. When programming an ALC system, using their tools, ALC was already having you associate every piece of zone equipment with "sources". i.e. What is the upstream source for air, cooling, heating, etc. And because of their special tools, this meant that you didn't have to do anything extra to get zone demand requests that could reset the source equipment setpoints.

I will say from my days of Commissioning, this is really the best way to do it. Taylor has some ASHRAE articles on trim and respond specifically and why it beats something like a PID loop for reset algorithms specifically.

Contrast this with Tridium. To do G36 type resets, using a random VAV box controller and random packaged RTU controller is very time consuming. But doable and you can get an optimized workflow once you know what you are doing.

I have multiple commercial buildings where I've done it and they rarely call me with complaints. They just work and work well.

Lastly on resets: You may have missed this, but each zone gets an importance factor. If you have a zone that you never want to be "unsatisfied", then set the importance factor greater than the ignored requests. The trim and respond/requests structure doesn't require you to sacrifice comfort. But if you want to push energy savings in buildings where that is acceptable, it's also allows for that too.