Right now, Fill looks at the color of the current pixel, and floods around filling to Pen color until it finds any border pixels of any different color.
When an outline is drawn over a background that already has a lot of colors going on (so that the outline has multiple colors inside), then multiple [fill] are needed to fill each color region (and no guarantees you won't get stray pixel artifacts at the boundaries)
This makes it tough for my class' animation project, where they [clear] and redraw every single frame; moving a small object with a fill color across the background means whenever it passes a background color boundary [fill] doesn't work (or multiple fills are required, which also means computing the locations to do multiple fills, which isn't really practical)
How about this: [fill current outline starting  pixels in direction ]? The turtle has just finished closing an outline; then [set pen color to ] changed the color. The algorithm starts by detecting the color under the pixel (which is the outline color), then moves inside as instructed, and then fills everything which is not the outline color, rather than everything which is not the under-cursor color?
Or an alternative method; [fill inside color ], where the user specifies the boundary color for the fill algorithm to stop at. User still has to pen up and move inside, but then fill doesn't need to check the color under the cursor
Those are interesting compromise ideas. The official right thing is for FILL to be a C-shaped block whose included script has to draw a simple closed curve, and then FILL fills exactly the interior of that curve, regardless of previous colors. (I guess if the pen color is partly transparent, then the previous colors are partly retained.) Your proposals are like that, in the sense that they pay more attention to the border color than to the interior colors. But they're like the existing floodfill in that you don't have to plan ahead while drawing the outline.
When Things Slow Down™. Or, I dunno, maybe sooner, if Jens likes the idea. In any case we should also have the existing floodfill.
I'll keep an eye out for whether an advanced student might be able to tackle a custom fill block.
bh I am intrigued by the C-block design. I guess it could 'help' by noting the position at the start, and when the inner block whose job it is to draw a closed curve returns, pen down and move to the remembered start position, just to help make sure it's closed? The C-block could also take two colors, the boundary color and the fill color, and let the inner outline-drawing block(s) assume that color and pen-down are taken care of.
you could have a fill on and fill off block, like pen down and pen up. (although you probably want a better name)
when fill turns on, note the current position as the first point
every time the sprite moves, fill a triangle from the first point, previous point, and the new point.
inflate the edges by a pixel so there aren't gaps between the triangles, but don't go past the corners.
don't draw degenerate triangles (triangles where two points are the same position)
Oh, I was talking about JS polygon fill, the equivalent of my C-shaped block proposal above. I don't think they have a floodfill primitive; if you do a search you'll find a bunch of messages about various people's ideas about how to do it so it runs fast.
whoops, didn't fully think that over. i think there should be some working method based on winding order? worst case you could still just have the fill on/fill off blocks keep track of all the relevant points. there's probably some reasonably fast method for this kind of thing already.
either way, it would be nice to have some kind of fill system where you can watch it fill before it completes, like how you don't need to finish a solid shape to draw lines. it would make debugging projects much easier.