Do yourself a favor and ask your reseller what exactly ALC means for you in the coming years. Don’t omit the "mandatory" aspect of the story.
I also started to comment the 4.0 thread on the forum and wind up with a long text (again 
) but finally didn’t post.
Personally I think 4.0 is what I had excpected from 3.5. So for me it’s 3.5+4.0 = 3.5. You don’t know yet what’s new? Let me know if i should publish the ‘what’s new’ text.
hehe, have a look at this FPS game monster in this video . That’s where game AI has to go to …
Aynbody reading license text?
1D. LIMITATIONS ON THE USE OF THE SOFTWARE FOR ALL LICENSES. Pursuant to this License, Licensee is NOT entitled to:
(…)
- Use the Content for the 3D Life Player for commercial usages or promotion purposes;
(…)
The hereabove operations, and more generally any operation not expressly authorized under this License, shall only be carried out by Licensee pursuant to a separate license agreement to be previously agreed upon and executed with Dassault Systèmes or its Licensors, on a case by case basis.
(…)
This one was NOT in the 3.5 license text. Did any customer get an e-mail before the 4.0 release with a notice, that this will changed? We didn’t. I mean I can imagine that there are companies that are build around the creation of Web3D content - they are affected by this intensively.
I've seen some interesting Virtools projects where unfortunately the behavioural approach (like promoted by Virtools) is used too extensively with a huge number of objects and lots of scripts. If you have then a look at the profiler you see the behavioural manager is eating a lot of CPU power. Why?
I think it's ok to say that the behavioural manager is currently working a little bit like an interpreter because it needs to parse the graph of BuildingBlocks in order to check and manage the activity states of the linked components. The more deep and nested your graph is, the more it needs to traverse the graph - at least potentially. It depends on the activity states of the links and BuildingBlocks. That's also why you try to separate and wrap parts that are only active once in a while. A manager-like approach (one script handles many objects) might be a better approach for such situations.
Recently I started to read a little bit about (low-level?) continuations and (higher level?) coroutines , tasklets , micro-threads , generators. Some of this stuff was or is in stackless phython. There are some interesting articles in regards of implementing game object logic using concepts like tasklets. Maybe something like a behavioural engine could be implemented using either signals-and-slots or these tasklets and would then probally not suffer anymore from so heavy performance penalties when using lots of scripted objects at the same time. This concept of micro-threads is also used for EVE-online - a very complex MMOG. Some more interesting links:
Game Smart on Coroutines
Multithreaded Game Scripting with Stackless Python
Stackless Python: about Tasklets
Discussion Thread about stackless python, co-routines, micro-threads etc.
Gamasutra: Game Scripting in Python