First of all: I'd not like to see turtle.py converted into a package. I think with the turtle module things should be as simple as possible and I don't see any need to put approx. 100kB of code into an __init__.py and be it only because there are hundreds of them and on cannot see from the name what's in there. I do not expect the avarage turtle user to look at the code, but certainly some teachers and instructors do even if they are not python specialists accustomed to the use of packages.

As far as I understood from the discussion the MAIN POINT is to make the turtleDemo accessible as easyly as possible.

So at first this needs a decision to put the demo code into the Windows-Distribution.

The next question is where to put it. In my opinion there are two possibilities.

1) The one mentioned by Alexander in msg119612: a turtledemo directory in Lib. 
2) To put a turtledemo directory into the Tools directory (in some sense the demoViewer is sort of a tool, isn't it.)

I quickly prepared a 'prototypical' collection with a modified viewer, which accounts for some of the arguments which came up in the current  discussion. It contains a turtledemo package. Please download it and have a look.

Each demo can be run by doubleclicking, as a standalone script, as well as from the turtledemo.viewer

If from the above options 1) were chosen or the package is somewhere else in the search path, on can - at the interactive prompt - do things like:

>>> from turtledemo import bytedesign
>>> bytedesign.main()

and also:

>>> from turtledemo import viewer
>>> viewer.run()

Morover one can load the examples into Idle and start them via the run-command. So one has a look at the code and moreover the possibility to make changes and try out, what happens.

I have renamed the sample scripts, omitting the tdemo_ - prefix, as 
this looks nicer (at least for me). The previous version turtleDemo recognized scripts with this suffix as belonging to the demo-suite and
added it to the examples menu. This was necessary because of a script, which cannot be demonstrated in the demo_viewer (two canvases). I changed this in my proposition in the following way: scripts that are in the demodirectory and should not appear in the DemoViewer's example-Menu, should end with _.py or some other extension.

To make the demo_viewer importable creates a special problem: the demos are imported by the demoViewer via the __import__ function, so everyone can add his own demos to the demo-directory and they will show up in the viewer. The original version (and even this one) can do this also for demos in subdirectories when started directly. (I've included as an example the geometry directory). This does't work yet for importing the viewer, I only provided a very clumsy quick and dirty solution and I hope that someone has a better, more bright idea to do this more elegantly and correctly.

Now for something completely different: how to make it easily accessible.

1) Put remarks (and links) into the documentation, near the head of the turtle module's docs. (Referring to 24.5.7)
2) Put a hint into the commentary/docstring of the file turtle.py itself.
3) I do not consider it a good idea to put the viewer.py into the 
if __name__ == "__main__" - part of turtle.py thus replacing the current demo. I think this part should demonstrate the possibilities of the module without recurring to extra use of Tkinter (as the demo viewer does). (I must also confess, that the quality of the code of the viewer, which I programmed back in 2006, does not reach the standards I tried to achieve for turtle.py)
4) BUT I'd find it useful to change this final demo code of turtle.py, so it - in the end - displays a message where to find more demos (i. e. turtledemo) or even to put there a question like ("Do you want to see more demos?") and two "turtle-generated" "buttons": "YES" and "NO". If one chooses "Yes", the turtledemo.viewer would pop up in a separate process.

Please consider this to be a proposal or a contribution. I'm very interested in discussing it further and bringing it to a quick and easy solution for Python 3.2. Unfortunately I'm currently involved in a project (also python-related) with very severe time constraints for the next four to five month. So ideas for enhancing the demoviewer and probably turtle.py have to wait until then and possibly will be an issue for Python 3.3

Best regards,
Gregor