A little background may be interesting:
Synthetic channels came about because there were occasionally requests for derived types being added that always follow the same theme - take some existing data, apply a function to it to create the derived type then making it available.
This is the primary use for the synthetic channels - up to 5 existing channels can be input, a function is applied to that data and the results then recorded. As they are an integrated channel, everything you can do with a normal channel you can do with a synthetic channel - custom graphs, gauges, alerts and STAT$ tag queries etc.
Normally I'd have embedded something like a Lua interpreter to do this BUT, although it's an easy enough language to understand, it's still quite complicated, especially for people who aren't programmers. After searching for a bit it dawned on me that, as we're on the Mac, and it already has a scripting language which has plenty of examples and documentation available, that's a candidate. Then it dawned on me that if we did use Apple Script, it would have access to WeatherCat's Apple Script interface internally, expanding its capabilities quite considerably. (See Appendix 1 in the manual for details of the interface).
So, synthetic channels can be used in the following ways:
1. Take data from existing channels, process it to a new derived type. The data from each input channel can be the current value, daily high, low or average.
2. Interact with the WeatherCat's Apple Script interface to pull out other data - for example to perform a query - as we've just seen with wind run.
3. Pull in external data to a channel (for example from the web/external device).
4. Used as a glorified custom alert - in this case you're just providing the logic of the alert where it needs to be more complicated than what can be done with a custom alert.
And combinations of the above.
Going forward, there are some things that can be added in the future - for example at the moment there are no persistent variables, so you can't store data across runs - you have to store the data yourself (in a file for example).
Secondly, if one is being used purely as a custom alert, it must still be enabled which means the data will be recorded (it's probably pointless).
Thirdly, it looks like we could use a few more.
The reason there are 5 is that at the time it wasn't known what the processing load would be like - it appears it isn't a problem, especially since the move to make the maximum processing rate once per minute (they were originally processed on every sample).
Finally, more information and notes can be found on page 56 of the current manual.
[Edit: There's also no way of setting a channel invalid at the moment - for example if you're pulling in say some astronomical data from a web site, and the web-site goes down, you can't set your channel invalid].