I think that your first decision is using ProntoScript or not.
My preference would be to make a page with a range of temperature buttons. I don't like the idea of changing the temperature simply because I, or someone else, landed on a particular page.
Without ProntoScript, you would build a number of nearly identical pages (differing only by temperature), then update the +/- button macros to issue the IR, then jump to the appropriate indicator page.
With a ProntoScript approach, create your main aircond page with the +/- button and a hidden page of temperature buttons. Give each of the buttons a convenient, unique tag name, such as 'TEMP_20', 'TEMP_21', 'TEMP_22'. At this point you can use "scheduleActions()" or "executeActions()" on your temperature buttons.
You can use string concatenation to build the button temperature button's tag name.
Rather than establishing a default setting that is executed every time that the page is entered, consider using a global variable to hold the current temperature setting. Air conditioners don't like to be jerked around. I am reluctant to make unnecessary temperature adjustments.
---
In my own work I built a generalized "call/return" library script that will push the current page location on a return stack and jump to a page. This allows me to build control pages for surround, temperature, video adjustments, etc., that can be called from any page. A "return" key on the control page jumps back to the caller. This is a little messy, but not complicated to get going. Once this is in place, any page can jump to a control page and return to the calling page.
To a limited extent a "return" can be done with a "browse backward" jump, but this simple scheme breaks down if the control involves multiple pages.