As one of Vuo's developers, I work on Vuo's engine (the thing that makes compositions run), work on nodes, and write documentation. You'll see me on the forums answering people's questions about Vuo.
I enjoy using Vuo to make live music visuals. My hope for Vuo is that it will grow into a community of people of diverse backgrounds and identities making lots of different artistic, useful, unique, goofy, beautiful, crafty, wonderful compositions.
Estoy practicando para ser competente en español. Si publicas en el foro en español, trataré de responder en la misma manera.
Starting with Vuo 2.0, we'll be publishing the full source code for each Vuo CE release — including the editor source and without the 1-year delay — at https://github.com/vuo
Because of the issues I mentioned above, in between releases the Vuo team will continue to develop in a private repository. However, we'll be in a much better position to accept pull requests since our private repo will be more in line with the public one.
The reason this workaround kinda sorta works is that the Render Layers to Windows/Image nodes disable depth-culling, so they always draw all of each object (rather than skipping drawing pixels that are behind another object).
The workaround only works well when both objects are 50% transparent. It doesn't solve the problem that Vuo doesn't know how to paint objects in the desired order, but it masks the problem because at 50% transparency the order in which objects are painted doesn't matter.
To answer your original question, if you're open to other coloring besides flat/unlit, another option would be to use lighting to fade in objects as they move closer. Add a light to the scene and limit its range to cover only the closer objects.
In your most recent composition, the problem is that the Make RGB Color node is executing too early. You're firing an event right when the composition starts, which goes down the line to create a random color, adjust its opacity, and render the colored square. That event slips in before the first event comes through Smooth with Duration. So before Smooth with Duration has a chance to set the opacity to 0, you've executed the node one time with opacity 1.
You can see this by feeding the output of Make RGB Color into Display Console Window or Record and Play Values. Look at the first line/item in the output: opacity (alpha) is 1. In subsequent lines/items, opacity goes to 0 and gradually increases from there.
When I have problems like this involving timing, I find that it usually helps to involve fewer events/triggers rather than more. You can get rid of the Fire on Start and Spin Off Event, and instead use an Allow First Event (Non-Flickering Layer Opacity Enqueue.vuo). That reduces your composition from 4 event streams down to 2. Oh, actually, you can reduce it further by replacing the Fire Periodically with an Allow Periodic Events (Non-Flickering Layer Opacity Enqueue 2.vuo). That brings you down to 1 event stream (Render Layers to Window : Requested Frame). That gets everything synchronized and it's easier to understand what's going on.