Excellent Jens! And what is your opinion about costume and sound names in dropdowns?
Hmm... it's always a compromise between making good decisions and allowing customization. Since costumes are often used in a stop-motion animation sequence and referenced by their position in the list of costumes, I'm assuming keeping this order for the drop-down menu to be the most common and generally user-expected choice, don't you think?
I completely agree that costums and sounds must be listed in the tab in the order they are created/used. As for the dropdown, it is good to me that the default order is still the creation order. But when I have many of thems, it is difficult to spot the correct costume/sound if I can’t find its name alphabetically. That is why I would like to have a flag in the settings allowing me to show them alphabetically in the dropdowns when I need it (to me, almost always)
hmm... I agree that the order of creation is probably not the choice that makes sense for most resources. Therefore, for sound names I guess the user might rightly expect an alphabetic order in the dropdown menu. But in the case of costumes the order has a very distinct meaning wrt to the next costume block. That is a semantic ordering that I wouldn't like to be overridden by some user-defined preference.
If messages and sounds is the most I can get, fine 
done 
Thanks for this good discussion, Stefano!
Jens, I'm not sure, but I think you're missing part of the proposal, which is to give the option to decouple the pulldown menu ordering from the costume-tab ordering. Nobody is proposing to reorder the costume tab, even as an option.
No, I don't think I'm missing anything here. I quite firmly believe that ordering the pull-down menu of costumes names in the same order as the costumes tab is what we owe the user, because - unlike sounds - that order means a lot in Snap. Consistency in meaning isn't a bad thing to care about when designing a UI
Even if the user explicitly checks a checkbox saying they want something different?
no checkboxes, no additional ones. If a user shoots themselves in the foot by adding a bazillion costumes to a single sprite then an additional preference setting isn't the right strategy to help them.
As a general design rule, customization is something I try to avoid at almost all costs, because it makes it so much harder for facilitators, teachers and ourselves to help users online and even f2f if Snap! looks and behaves differently from user to user.
As Jens said, what he thinks is
He doesn't want to add infinite customization switches just to accomodate every single user need, but he prefers to aim to a meaningful set of customization switches that make a good work for a reasonble amount of different profiles of Snap users
yes, exactly, from a pedagogical point of view. When I'm in a workshop with 20-50 persons the one thing I don't always want to explain is the importance of carefully setting the "right" preferences for each activity.
So you made me think of a further customization 
Could it be interesting adding the ability to load a "settings" file that allow teachers and students to work with a perfectly customized view of their UI for their lessons? I guess this is something along the line of the extensions you know I love 
That's a difficult topic, one that I'll admit makes me more than nervous.
On the one hand we're experimenting with massive and deep "microworld" customizations like the one Bernat and Paul are woking on for elementary school math, and there are your BloP extensions that really turn Snap into a specialized microworld for teaching even other programming languages like C++, PHP and LOGO. Such projects legitimately raise the question whether Snap! is or could / should be a programming language for making educational programming environments, such as Racket is a language for making programming languages, and such as Smalltalk was meant to be one.
On the other hand Snap! offers a peculiar set of features emphasizing particular ideas that we believe to be "powerful" and even having the potential to be "life changers", such as first-class functions, recursion, prototypical delegation (OOP), and now linear geometry operations etc. etc. and we really wish for students to get access to these powerful ideas.
Yet, in practice, every time an instructor wishes for a customization it is to hide or take away exactly these traits in order to teach something "easier" and "less advanced", so learners are "not confused" by seeing things they "don't need" to understand. Almost all the time it is to hide functions in favor of a strictly imperative "coding" style, and very often the wish is for teachers to control exactly what students can access and even explore.
While I - mostly - disagree with such choices I do see their pedagogical value, at least sometimes. If it's Paul or you, Stefano, these designs are always pedantically thought through and rigorously scrutinized and iterated over. However, I'm sad to say, in the vast majority of cases it's teachers themselves who cannot handle the concept of functions. It's professors who don't understand variable scope. It's instructors who bend over backwards to mutate compound data, because that's what they (were lead to) believe is what is "right" in Java (which often isn't even true). They believe that they know the "easy" imperative way that's "enough" for their students, and that using functions is somehow "hard" and "advanced".
I've never been approached by a teacher who wanted to hide all command blocks and take away loops so they could teach recursion-only.
To me the very essence of what we're trying to achieve with Snap! is to make a set of powerful ideas in computing accessible, and to let learners experience that their life will be better because of them. That includes not being overly strict about a certain programming style, allowing projects to use different ways to express algorithms side-by-side, and to even allow and encourage mixing paradigms.
If it were just me I'd require every educator who wants to hide a feature to prove that they know it. Again, you're an exceptional special person, Stefano, but the vast majority of teachers and even / especially government officials suggesting such customizations are simply too lazy to leave the comfort zone of their FORTRAN style thinking. Most of them also believe that "a little bit of coding" is all that's required of them.
So, to me it is a question of which features to spend my time on. I'd much rather improve the overall usability, stability, scalability of Snap! for everybody than on perfecting a specialized interface for some teachers to take away Snap's good parts. Can you understand that?
That said, I do wish to support awesome extensions like BloP. I believe there's a sweet spot between customization and making good design decisions. My focus is decidedly on the latter, but in Snap! we're already supporting way more customizations than any other blocks based language I'm aware of, except Blockly, which isn't a language but a framework for making editors.
Discussion like this one are really great! I'm very glad you've pointed out some glitches that were pretty obvious oversights on my part, and I really love it that you did. This is exactly the kind of discourse that ends up leading to better designs. Thank you!
(Incidentally: I didn't know about that, and this is really interesting to me. I hope Bernat and Paul are wanting to share their work in progress!)
I understand that this is definitely something that should not be on Snap's shoulders. But (unfortunately?) all the ideas that Snap wants to emphasize are embedded in a so good environment -carefully chosen in order to make them easier to be grasped- that it makes Snap an excellent candidate for the implementation of a lot of other ideas that other teachers would love to be as easy to be grasped as they are in Snap.
I must admit this is certainly true, at least for me. I always hated even the concept of variable. Why -it was my thinking- I have to use variables when I don't use them when I explain a "procedure" to someone else (when I give them instructions)? And, finally, after many years, I found Logo and then Scratch and then Snap that allow me to create powerful apps and tools without the need of knowing anything about variables. Of course, variables are there. But they are hidden. So I can start doing interesting things without having to know about "weird" concepts. After a while, when I want to do something more complex, something that is not built-in in the language, this is the moment to start to learn about variables. So I understand them, because I NEED them, and they are exactly what I need and they are no more just the way "things are done in programming"
This is true of all programming concepts (and of all science and human knowledge). That is why I like the idea of having "minimal and incremental environments" where you can add step-by-step more and more concepts when you need them. And the environment is not cluttered from start with things that I don't understand.
I can see the discovery process of the curious learner that you see (when I was twelve I was one of them). But the curious learner today is not the only audience of programming. And I have seen too many non-curious-at-the-beginning learners that have dropped programming just because they where discouraged by having to use tools that (they were right) they didn't see the reason why they had to use.
Yes! That is why you are (again, unfortunately, I'm sorry) the target of all the requests of us enthusiast alternative-languages' creators
Yes!! I do completely agree. So... you'll get of course more requests from me in the future
What a great idea! We should celebrate Church's birthday each year by hiding all the commands that day.
Haha! You know, you no longer qualify as "teacher" since we're in this together
Yes, I wouldn't not do that either. When teaching recursion I would point to the more compact and more logical way of expressing a given computation recursively. Loops should be there, in order to compare the two different ways of expressing the same computation.
That would be fun 
Whoa, Church's birthday is coming up in less than 3 weeks, better get to work then, haha!