Factor the photo image handling and processing out of Tk, make it independent of presence of X11 and other graphics core (leave only the absolutely minimal graphics-dependent part in Tk).
(DKF: Note that in 8.6 there is already some splitting of the image code into manipulators and renderers. I think that, of the code that isn't doing rendering, the only part that is critically related to having a GUI is color name parsing. See also Tk FRQ 783802 Tcl'2003: Split photo masters into Tcl package .)
Benefits for the student
An opportunity to extend their familiarity with "C" code, to work with a large body of code they didn't write themselves, and to work within a previously defined framework (namely the TK Image infrastructure).
Benefits to the Tcl Community
This makes an important part of graphical operations available to display-less applications, like report generators, web servers (on-the-fly graphics), etc.
Notes
AMG: Would the image loading/processing/saving code go into the Tcl core or into a separate package required by Tk? Would this separate package be bundled with the Tk sources, possibly with an option to build and install it independently of the rest of Tk? Or would it be bundled with the Tcl sources, with options to build or skip it? Or would it be a new project that would subsume Img? As much as I'd like to be able to process images without having a GUI, I don't want to see Tk get any new dependencies.
I recently wrote a Tcl image processing extension for a specialized application; I made a separate "tk" version of the extension that interfaced its internal image format (a Tcl binary array) with Tk photos. It worked out pretty nicely.
DKF: I'd like it to be a separate package that Tk would package require, though I'm less sure about whether it would be distributed with Tcl or Tk.
AMG: I assume the color name parsing code would also have to be factored out of Tk, since it's needed by the image code. This can get very tricky, since parsing color names is done by the X server (evidence: [L1 ]), and I imagine we wouldn't want any X dependencies in a standalone image library. What can be done about this?
DKF: Colors of the format “#rrggbb” can be handled internally – actually, we might already do this to avoid round-tripping the server; can't remember if that patch of mine got committed :-) – and we can add the “web-safe” color names too. Basically, it comes down to putting the color names into a hashtable and doing lookups against it (after following application of some standardized normalization rules I presume, or maybe they'd be applied lazily if the lookup fails? Not done a design study yet…)