I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further and allow/demand naming of blocks:

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    end 

Then becomes, not wrapped in end-check, but:

    check(arithmethic-test):
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    end(arithmethic-test)

Or something similiar. This makes mis-matching "end"s (either typos or artifacts from cut'n'paste coding) explicit errors that are easy to spot, and identify.

It would add a lot of verbosity, of course. As for ";"/"end", consider (the presumably valid):

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6
      9 - 3 is 6
      5 > 4 is true
    ;

That trailing ";" is going to trip someone up. Also consider (cut'n'paste-with-quick-edit):

    check:
      4 + 5 is 9
      1 / 3 is 2 / 6;
      9 - 3 is 6
      5 > 4 is true;
    end

Is this valid?

I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token).

So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word for each construct, there's a needless mental burden; if you pick a uniform strategy ("end-<kwd>") you potentially get less readable code. And either way it's far more verbose, as you point out.

Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them.

My preference is to use ; for one-liners, but end where you have a multi-clause entity and you want to be able to clearly tell where it ends. If we find that there is general agreement on this, we can make it a context-sensitive check, à la indentation. Then, a program generated by a tool can do something consistent and ignore all these checks, whereas human-facing environments would enforce them (by checking or correcting).

As for your examples, to my Pyretical eye, the third of your examples (with the dangling ";") looks just wrong. However, your fourth example is syntactically incorrect.

> Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them.

I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag? (you type case, the editor appends esac (but below the point you're typing)):

    1:   |   #your cursor at |

    2: case|
    
    3: case:
         |     # you hit enter or something, ready to fill in
       esac    # editor has closed block/statement

I imagine typing-skills isn't much of an issue when editing/copying text -- as opposed to typing in new code?

An express design goal is to not bake in assumptions about an editor. Programmers really like their editing tools. I've lived through the waves from vi to Emacs to vim to Sublime Text to what-have-you. We'd really, really like to make the language pleasing to work with without depending on an editor (indeed, each of us seems -- perhaps by accident -- to be using a different editor for Pyret, which may be influencing our decision).

When editing/copying, it's not typing skills but editing skills, which are arguably subtler and even harder.

Your point about programmers having favourite editors (which I consider valid) contradicts the point you made about an important part of your audience being middle/high schoolers, which I don't think have such strong preferences towards one editor or another. It seems to me that you are making compromises to cater to the needs of an audience which is much broader than that you have identified for the language.

It would be a shame to compromise the design of an interesting language just because the target audience is not clearly defined.

I have many target audiences. I mentioned middle- and high-schoolers in response to various other questions, but I don't anticipate them being the largest audience. I expect the biggest audiences to be introductory college-level education and second/third-year courses on "paradigms" (blecch) that want a flexible language to illustrate several concepts. Finally, I am also consciously building a language and book to appeal to the working programmer who has not learned to think of computation as primarily producing values, and would like to quickly get up to speed with that idea.

All of these are educational audiences. I don't see how one can define the audience more clearly than that, given that I have no control over any of these audiences.

Having ; on a new line is valid, but having both ; and end on a block is invalid.