The problem of course is that for every problem, there are at least 3 RenPy solutions that will work and an extra couple that will work enough. Then a whole bunch that will technically work, but will be a pain to maintain.
Time.
I think I've written at least 3 solutions here on the forums in the past. Some better than others.
Each generally revolved around a time "period", where each period was akin to "Morning", "Afternoon", "Evening" and "Night".
"Morning -> Afternoon" ...
time_period += 1.
My 4th attempt (attached), switched to using the actual python time and date functions - then a function that would tell you what period a specific time was in. That way, I could advance by period or by hour or even by the millisecond.
Problem was I got bored and never expanded the functions beyond my initial testing.
You must be registered to see the links
By all means, take a look. Just realize it's only about 10% of where I planned to go with it. The list of functions related to time would have been expanded to do advances in other ways at the very least.
Rooms.
Aghhh... Open world.
I hate open world. 
My test project for
time was originally planned to be an attempt to figure out open world mechanics (and the reason I became bored very quickly). Instead, I focused more on the time and date and making a pretty interface that looked like the iPhone calendar.
The basics though are that you have a lot of connected maps. Each screen/map can be a room. Each button takes you to a different
screen. You should be able to write a full interactive map system with zero story, as the maps connect to each other.
Beyond that, it depends on the style of your open world. Some games will have clickable hotspots (usually representing people) who you can click on to have a conversation. Those hotpots will be shown/hidden depending on rules custom to your game. Alternatively, some games will have some code before the new
screen is displayed that checks if some sort of event will be shown instead. Or a combination of both.
Events.
Ah. The least formally utilized of your wishlist.
Most developers just end up writing spaghetti code where they have lots of variables about various things happening within game and check those values to see whether the story should advance. Zero framework... but clearly, it works.
You might want to re-check the cookbook for things like "quest trackers" or "quest management"... since those are pretty much what I think you'd be wanting.
Personally, I wanted to write an events systems at some point that had a list of event-IDs. Each event would have a list of prerequisite event-IDs that must be complete before that event becomes available. Then perhaps an "additional requirements" field that must also evaluate to
True before the event can become available. At least two lists would be needed, a list of available events and a list of the active ones. Each time the player enters a room, the list of queued events is checked to see if there are any events with an (newly) empty prerequisite list and the "additional requirements" are met, then the event is added to the active list and removed from the queued list. My theoretical goal was to write it is such a way that open world games could be played like a linear game, where the game itself picks an event to do next - without the player having to visit a bunch of empty rooms or grind pointless points. The problem though isn't writing such a system... it's writing it in such a way that new events/quests can be added/removed/updated as the game is expanded - without it breaking.
I'm not sure how much any of that helps you, except perhaps to point out that RenPy development is a bit chaotic and sometimes it's better to just dive in than spending time looking for an ideal solution.
