Your example, though, actually makes fly-weights take up way more than twice as much space (I think).

You're right.

So, that's how I interpretted the situation you were laying out. I assume I just misintrpretted it... but how exactly did I?

The GoF example was dealing with a WYSIWYG word processor, so "character" was more complicated than a single byte.

For example: A naive implementation of a bitmapped character in a word processor might (in Perl) look something like this:

my $char = bless {
    char => 'e',
    face => 'Times',
    size => '12pt',
    bitmap => '... some binary data ...',
    row => 12,
    column => 22,
}, 'BitmapCharacter';

...
$char->render # draw a 12pt Times letter 'e' at row 12, column 22
[download]

So if we have a a bit of text that says "errol eats enough eggs everyday" then we have 6 x 'e' BitmapCharacter objects that only differ by their row and column attributes.

In the GoF language we say that the row and column attributes are extrinsic state - they're dependent on the characters context (as opposed to intrinsic state which is context independent).

The GoF Flyweight pattern is to rip out the extrinsic state from the object so we'd have something like:

my $char = bless {
    char => 'e',
    face => 'Times',
    size => '12pt',
    bitmap => '... some binary data ...',
}, 'BitmapCharacter';

...
$char->render( 12, 22 ) # draw a 12pt Times letter 'e' at row 12, colu
+mn 22
[download]

So the container now has to pass the extrinsic state and we can use the same object for each occurance of each letter - saving lots of space.