I thought about secret codes for scenarios and scenario bundling.

For the scenario bundling:
Scenarios can be bundled. You select such a scenario bundle like a normal scenario, but when you do so, a new selection shows up showing the parts of this scenario group. ( Technically this can be made with either naming conventions or a new subdirectory structure. )

For the secret codes:
If you want to make  chained scenarios, which are meant to be played one after another secret codes for each part would be great in my opinion.
On the end of every scenario a secret code is shown. To enter the next scenario part, you have to enter the right code, before it starts.
 
Technically this means we need crypted passwords for scenarios. In the glest binary we will have one secret code, which is used to decode/encode these keys. The crypted password can be set in the scenario xml. This will be used to verify access to the scenario and will be shown decrypted when you win a scenario. We need a new tool for scenario creators which will encode the secret words.
 

Wouldn't it be better, if you write a "do not load" script at the beginning of the scenario, then after the first scenario you run a "next scenario" script? Ok, it can be cracked, but what can not be?

I think the statistics idea storing all the scenarios which are won in the statistics is a good one, but this is another extension. Regarding multiplayer and account based statistics( in the web ? ) this is an endless story of its own. The whole statistic thing is a story of its own, and we should not start it yet in my opinion.

For the secret codes:
I think there is no need to make them really crack  save.
Of course someone could easily look into the code and see the secret code and write a glest password decoder based on this. But I think
this will not really be used by people who want to play. There are several commercial games which use this method and for all of them a password decoder or pw-lists are available soon! But they are still be played the way its meant.
For the player its fun to reach the next level and he can continue later where he stopped. I'm shure this new features will also motivate modders/scenario creators to build us more complex stuff.
And it should not be only a lua function! These basic things should be a part of the normal xml desription of a scenario. In addition lua functions should be able to access this "show code"  things.

I thought a bit more about the code "security"...:
We cannot put the code into the scenario xml-code itself. It would be too easy to crack it, when you modify the xml to show the decrypted code immidiatly with a faked "you win" message. The code should be in its own file and its created using the xml-file itself.
Maybe we should create a checksum or something based on the xml-file.Then we encrypt the scenario password using this checksum. If someone tries to "crack" the password using a modified xml, the checksum will change and it will not be possible to decrypt the password.

Why not just have something in scenario 1 that writes to file, and then have scenario 2 read from that file?  This could have a lot more implications than just unlocking new scenarios, like having something you did in one scenario affect something in a later scenario, or branching scenarios based on the previous outcome.  Maybe some psuedocode will demonstrate what I mean.

Scenario 1:
when beaten,
write to file scenario1 beaten=1Scenario 2:
read from file scenario1
if beaten=1
then RUN
else DO NOT RUN

---

Scenario 3:
when beaten,
write to file scenario3 badguy==alive
then badguyalive=1Scenario 4:
read from file scenario3
if badguyalive==1
then run script badguyreturns

---

Scenario 4:
when beaten,
if merlin==alive
then merlin_dead=0
else merlin_dead=1Scenario 5a:
read from file scenario4
if merlin_dead==0
then RUN
else DO NOT RUNScenario 5b:
read from file scenario4
if merlin_dead==1
then RUN
else DO NOT RUN

OK, its indeed not really possible to have really secret keys and we don't need them.
I just want to describe my initial idea again:
Lets say we have scenario A,B,C which are meant to be played one after another.
If A is successfully finished a code is given that is needed to enter B .
So in the xml-code for scenario part A you will find a win message which contains this entry code for B. What I meant with crypted is only "not instantly readable".
Even simply using the HEX code would be ok as long as its not too easy to read, so no real encryption is needed.  If someone really wants to cheat he can do so and using hexcodes or a bit string will teach those kids something useful for life   .

So what we basically need is:
- A secret code input screen which is shown if needed before a scenario starts
- A standard win message which displays the code for the next scenario
- A lua possibility to show the code for the next part if you want to build your own win message

and the scenario bundling thing mentioned in my first post.

I know it from my sons too.
And ask your son, I bet he had his fun ...

...with all his little pieces of paper with secret codes

Its like gollum in lord of the rings "My treasure.. it belong to me" 

Sorry for DP'ing, I hadn't really looked at this before. 

Why not just have something in scenario 1 that writes to file, and then have scenario 2 read from that file?  This could have a lot more implications than just unlocking new scenarios, like having something you did in one scenario affect something in a later scenario, or branching scenarios based on the previous outcome.  Maybe some psuedocode will demonstrate what I mean.

I think this is a very good idea though, actually, I think the posted pseudocode is rather limmited. It kinda looks like in all cases it just boils down to whether or not you will be allowed to play the "new" scenario or not. 

But his could actually go much further, like "moving" some sort of game-state from scenario1 to scenario2.
For example, in omega's Labyrinth, it could be used to determine which of the four heroes was still alive from one stage to the next and not bring back those who had already been killed.
This doesn't apply only to fixed-number-of-units scenarios such as that one, it could be used in more "common" scenarios in which you would not only have to beat the oponent but also make sure you still had enough "firepower" to take on the next scenario.
On the other hand, on the first scenario the "foe" might actually be two allied foes (same team) and the winning-condition to beat just one of them. The state of the other foe might carry on to the following scenario too. On the same scenario1 case, the fact the secondary foe was still alive or not might actually be used to choose alternate scenario2 scenarios (say scenario2a and scenario2b).
Still another option would be for you to have your own allied player, and whether it was still standing or not when you beat the foes could have an impact on how the next scenario would be laid out  too.
The possibilities should be limmited only by what the implemented Lua allows you.  

I think what you said is great Titi! I always wanted to make missons, I allredy have but you can play the 10th before the 1st.