That’s the list I meant 
I have others like:
But being specific it’s important
This one is unsolved problem for all offline renderers. It’s not just limitation of Cycles, so I’d leave this one out. If you deform a mesh, it’s no longer the same mesh, storing the same vertex and triangle positions in memory, so you can no longer keep it in the memory just once, and reference it multiple times.
If topology doesn’t change, one could in theory share index buffers between instances. The bulk however still are vertex buffers (+ normals and maybe tangents), those must be separate for each deformed mesh.
Two quick ones, that already have patches around:
More in general, for caustics and for iridescence we can go with tricks, but with performance and production features we are really a few steps behind
I have the second one fully implemented and running in our build
For the first one, do you know what’s the patch? I know there is a task, but I don’t know anything about any patch.
Thanks!
It’s one of those complex patches, I doubt I’m able to update it to today’s code, but I’ll try… why not? 
What about animated instances that are able to play the animation at random playback speeds with random start frame, that’s an important one, for example to use proper vegetation in animation.
Sounds like something that can be done with upcoming overrides
I hope so, it’s impossible to animate a forest without something like that
@StefanW I’ve been thinking about this… couldn’t be possible to store the base mesh and then have a delta for each deformed mesh?
Would that take the same amount of memory than to store the whole mesh, deformation included?
Deltas would take the same amount of storage as the original vertex positions.
Ok, so it’s a non-sense…
And I keep thinking in ideas that could be useless, but… could be possible to do the deformation at render time? I mean, avoid storing the deltas and applying it in some way that avoids having to store all the deltas in memory, so the memory benefit stays while we may loose a bit of performance at render time.
I don’t know if this is kind of phantasy tinking, but I had to ask.
(I’m thinking on some kind of cache/shader deformation, something like that)
Other render engines such as Appleseed or LuxCore use a different type of algorithms like photon mapping to create caustics:
You can do that with rasterizers, during rasterization. That’s why game engines have such easy time rendering forests of animated trees. It’s purely a shader effect though, albeit a powerful one. But for ray tracers is not that simple.
For example UE4 implemented first usable version of Ray Tracing in 4.22, and now extended the support for many more features in 4.23, including being able to raytrace instanced static meshes and world position offset (the “rendertime deformation” thing) for skeletal meshes. But even they still warn that world position offset does not work on instanced static meshes, so even they have hard time supporting that in UE4 as soon as rays start to get traced. They can render instanced static meshes fine, as long as they don’t have that world position offset shader effect
If it was easy, someone would have done it by now. There’s chance someone will figure it out in future, or we will have so much RAM it won’t matter.
The kind of workaround for now, in offline rendering, to do animated forests, is to have one animated deformed tree and sample it’s animation at let’s say 4-5 specific points evenly distributed along animation time. That doesn’t give you unique animation for each tree, but at least there are 5 unique animations which are often enough. Still, if you have forest made of 4 different trees, each other sampled at 5 different time points, that still means increase to equivalent of storing 20 trees in the memory.
Even easier is to render just one point in time, and have some generic animation of just leaves flapping around. Then render each tree each frame on the exactly same time position. It will still cost same as single tree, but it only works for tiny movements. Not really for trees violently swaying in wind.
On top of that, when trees violently sway in wind in one direction, it means you can not rotate them randomly too much, as they need to follow the wind direction. That means it can now become more obvious that it’s just one or a few same trees instanced, so you may need even more tree variety.
Generally, forest in the wind still remains one of those very hard problems to solve. I’ve broken my teeth on it myself.
Animate single trees on transparent background, then composite them?
I don’t even know where to begin to describe how much of an insufficient answer that is
I agree, that’s not an option, and in any case it doesn’t not solve the problem of rendering 20.000 high resolution animated trees.
So how would the render engine even read them?
With an out-of-core system, I mean, some kind of out of memory cache, may be fast enough to not have a super high impact, but once again, I’m just thinking out loud, it may make non-sense.