>> PS: I have been working with VW recently and I really found 
>> namespaces getting in my way all the time. Also the integration of 
>> namespaces
>> in VW is badly supported at the refactoring level and other tools. So 
>> this is often a pain.
>
> I agree with Andreas and Stef.
> Working with Seaside in VW right now, I can find 3 (three!) "versions" 
> of Date in VW (Core.Date, Squeak.Date and Seaside.Date)!
> It kind of sucks to have to extend Seaside.Date with date method 
> extensions already existing for Core.Date for this local shop.
>
> Maybe namespaces of VW helped to get seaside ported to VW at all, but 
> I'd prefer to have an ongoing desire to unify classes, which _are_ 
> intended to work the same.
These 3 Date classes are the result of difficult design decisions.

1) Seaside uses Duration, DateAndTime, Year, Month, Week, and maybe a 
few other that are part of so-called Chronology.
These classes are not available in VW.
2) I was lazy and rather than re-implementing Chronology in VW, I ported 
the Chronology package to VW.
3) Porting Chronology from Squeak to VW created name clashes for Date 
and Time classes. VW namespaces
helped here with Core.Date and Squeak.Date, Core.Time and Squeak.Time. 
Note that there is no clash for
Timestamp (TimeStamp in Squeak) and for Timezone (TimeZone in Squeak).
4) Now that I had two different classes for Date and two different 
classes for Time, I had to decide which
would be used in VW Seaside. I did this by subclassing Squeak.Date and 
Squeak.Time as Seaside.Date and Seaside.Time.
Again namespaces helped here.

I'm not that proud of the result that looks more like a hack, but it has 
worked fine so far and without too much work.
Many Seaside add-ons like ShoreComponents, SeasideTesting, RSRSS port 
nicely and silently to VW thanks to the hack.
A probably better solution would be to re-implement Chronology in VW 
(with the ongoing desire to unify...). I feel however
that there might possibly be some potential semantic differences between 
VW and Squeak in this area that would create
some different issues with some other difficult design decisions to come.

So, yes, VW namespaces helped (a lot!) to get Seaside ported to VW.

For your specific problem, rather than extending Seaside.Date with 
methods that exist in Core.Date, you could also
change the superclass of Seaside.Date to be Core.Date. Then, you may 
have to extend Seaside.Date with methods
that exist in Squeak.Date :-)

If some applications need Core.Date and some other need Squeak.Date, 
then you can try defining different namespaces
and define MyNamespace.MyApp.Date and MyNamespace.MySecondApp.Date, and 
extend them as needed :-).
That looks complicated but that would probably work.