I too am interested in a units package for squeak. I have implemented
a units package in another language (Mathematica) that handles Sam's
"general case which ends up with composite units like furlongs per
cubic fortnight per dyne centimeter." I agree with Sam that "you
then need an algebraic system with mappings for unit definitions (dyne
cm = erg, etc) so these composite units could recognize whether they
were compatible or not and if the units could be reduced or mapped to
another unit." 

The only two "mathematical" functions I used from Mathematica
to do this were one that told me whether a set of vectors was linearly
independent, and one that returned combinations from a set, taken N at
a time. I know squeak already has a function for returning combinations
N at a time, so all we need is the linear independence checker. Can 
someone point me to a linear algebra library for squeak?

Things that gave me grief before, and that would be good to do more simply
this time, are non-absolute temperatures, lists and tensors, automatic
unit simplification and functions other than (+ - * /). 

What's the problem with non-absolute temperatures? Well, when I say
that I heated my dinner from 40 Fahrenheit to 400 Fahrenheit, I would
like to keep the same units, and describe the temperature difference
as 360 Fahrenheit. If I want the heat put into dinner, I multiply dinner's
mass and heat capacity by 360. But if I let the oven cool 40 
degrees, and then want to compute the density of the air using the ideal
gas law, I want not 360, but 360 + 459.67. As human beings we figure out
the right thing to do in each case from context, but I don't think Squeak
can be that smart. The resolution I've used before is to never use
non-absolute temperature scales for temperature differences, only for 
temperatures. The Mathematica units package handles this automatically; I
doubt that feature was really worth the complexity it cost.

What's the problem with lists? One must either keep the units once per
list, or once per element of the list. No matter which one chooses,
half the time one wishes it were the other way. My bias is to keep the
units of homogeneous lists only once per list, because this preserves
the information that the list is dimensionally homogeneous, and
without this I found my code became cluttered with checks to see
whether a list was homogeneous.

What's the problem with automatic simplification? Well, when I divide
newtons per ampere squared by farads per meter, it's a very good bet
that I want to see units of ohms squared. But when I divide miles by
hours, I probably don't want to see this simplified to knots. Humans
have a lot of heuristics for this, learned in years of classwork, and
learned differently in different disciplines. I found that I could do
a pretty good job of reproducing my own heuristics by simplifying only
if I could reduce the total number of base units required, not introduce
any fractional powers, and I restricted my base units to the set of
units I started with plus joule, watt, pascal, newton, coulomb, volt,
ohm, farad, henry, tesla, weber, and siemens. Using units in the original
expression before the units above will usually keep absorbed dose in
rads, instead of converting it to pascals.

What's the problem with functions other than +, -, *, and /? The problem
is that there are so many of them. :-) In the Mathematica package, I
kept encountering functions that should work with dimensional quantities
but didn't. See the functions section on the web page. If someone can
figure out any way to avoid the same proliferation of tiny methods in
the Squeak units package, that would be a very important contribution.

An HTML version of my (Mathematica) units package is available at
  http://stanheckman.com/a/98h/glimpsedotter/html/PhysicalUnits.html 
The (brute force) automatic simplification section might be
interesting to someone implementing similar functionality in Squeak.

-- 
Stan