Well, actually my point is about user awareness. Today you just download Cocoon, read the docs, type ./build.sh and see some fast-scrolling messages muttering about unstable stuff, and that's it. I'm thinking of something more specific that forces the user to know what she's doing. A different property/target (./build.sh -Dinclude.unstable=true)? A different file to edit (local.unstable.block.properties)? Everything would do: but clearly a message that scrolls during the build is not enough.
Well, having it disabled by default is a clear sign?
If we disable by default unstable blocks, first-time users won't even be exposed to such things as Forms, repository, OJB, portal, petstore, linotype, etc., which could be *huge* selling points for Cocoon, IMHO.
I'm not that worried about people being confused by two flow implementations, if one of them is in core and the other one is in an unstable block. I suspect first thing most people will do after downloading is running the samples. If samples for unstable blocks sport a large, red-lettered warning, we have nothing to fear, again IMHO.
Ugo
