Hello Michael
If you select a technology that can give you control over separate lighting channels or colours of a fixture, almost all of them should give you the ability to setup as many moods / scenes as you want.
openHAB2 is excellent at setting scenes, as long as the infrastructure of your property give you the flexibility.
Okay, that’s good to know, it will help everyone give you advice / ideas that are more relevant to your area.
For example, I understand that ZWave hardware use difference frequencies for different regions.
I’ll assume that the same restrictions apply to other wireless technologies.
Likewise, there are the electrical wiring regulations to consider too.
For example, the Velbus hardware that I distribute are all CE approved, but I don’t know if this is enough for use in Canada
Arrrr you’ve fallen into the “old” trap.
When you say “Lighting circuitry to be standard”, which standard are you referring to 
“Classic” domestic lighting wiring is like a bus.
Connection starts at the consumer board and travels around the property, branching out for switches and lighting circuits.
Whereas a centrally controlled lighting system will have all circuits wired back to a common control location, where relays and dimmers are mounted. (It’s totally acceptable to have multiple Nodes of control, rather than 1 central one. Consider a hotel where each room / suite has it’s own isolated power / water / heating / cooling supply, with it’s own control node)
These control modules would then be controlled by buttons, panels or software elsewhere in the property.
While this drawing is specific to Velbus hardware, the logic is sound for all of the centralised systems.
KNX, Loxone, Crestron, AMX, Mode lighting, Control4, Rako, Niko and so the list goes on and on.
You’ll see on the left hand side of that PDF the layouts for a heating system, as each of the Velbus glass panels contain powerful HVAC thermostats.
It doesn’t really matter what you heat or cooling source is for the Velbus thermostats, as they are more concerned with giving you the ability to easily zone your property and route heat or cooling where it’s needed.
For example, you could reference the PDF and imagine that air ducting dampers and a central chiller are being controlled, instead of water valves and a heat source.
The real magic is that the Velbus thermostats can’t demand both at the same time, but will easily flip between the two systems as needed, even with a comfortable temperature where neither are in use.
I think you have it in a one 
It’s not that Velbus or KNX, Loxone, AMX, Mode Lighting, Niko, Rako, Crestron or the others are “Non-Standard”, but it might be that they are a commercial / high end approach.
This over simplified drawing hints at the difference, I drew it in a hurry and haven’t needed to improve it yet.
http://www.mdar.co.uk/dl/Hybrid_Classic_Lighting.pdf
You have a perfect understanding.
Velbus, like KNX (with some very important differences), doesn’t require a central control unit.
Every modules works with every other module to form a collective.
Each module listens to the bus for status’ from other modules and responds according to it’s own configuration. (Which is done using the FREE (Windows) VelbusLink software, that treats the network as a complete system, updating each module as needed via the single USB interface.)
openHAB2 then works as an umbrella or control surface, rather than the “Brain”.
As a wise man once said, “Let openHAB2 control the thermostat, not BE the thermostat”.
What I particularly like about openHAB2 is the way it brings different technologies together, the simplest use case might be where an event on one system triggers an event on another.
A great example of this is where people have used button events in Velbus to switch devices on different systems.
The simplest example might be this rule
rule "Another_Switch Toggle" // Where Another_Switch is an Item linked to a device that is dependant on a different binding.
when
Channel 'velbus:vmb2gp:c5053467:0B:input#CH1' triggered PRESSED // Button 1 of a 2 button Velbus glass panel
then
if (Another_Switch.state == ON){
Another_Switch.sendCommand(OFF)
}
else {
Another_Switch.sendCommand(ON)
}
end
You “could” in theory, create all of the connection logic in openHAB2 rules and not configure anything in VelbusLink (which some companies do), by why make life hard for yourself?
Regarding reference material, what kind of thing are you looking for?
Do you want examples of installations or technical documents?
I’m happy to help with anything specifically related to Velbus configuration or Velbus within the openHAB2 environment.
Good luck,
Stuart
Similar threads on this forum
and there are many more great stories on this forum