As for now, Sugar includes generic types like List, Disctionary, etc.
Do you plan to include Delphi-style for RTL, like TStrings, TObjectList, etc? Will it be possible? Like ShineOn-redefined! 
If yes, it will be cool to have common back-end for Delphi and Oxygene apps, and it greatly helps for translation of Delphi apps to Oxygene!
yes. check out the “Legacy” portion of sugar.
assistance and porting of SineOne classes over to this would be appreciated; but keep two things in mind:
(a) ideally, legacy should use Sugar, ie be written as cross-platform code built on Sugar.
(b) i think lots of contributions to ShineOn are rather directly “borrowed” from the VCL code. we can’t have that for Sugar and Sugar.Legacy; we cannot use code that’s copyrighted by Embarcadero, its got to be all fresh code, licensed compatibly with Sugar (ie BSD)
IMHO, now we have FPC-codebase, so some RTL ideas can come from FPC sources.
But personally, I did not think that it will be useful to directly port any Pascal-based sources. Sugar ability to rely on platform-native RTL via mapping must be used instead pure-pascal codebase.
i see this as two levels: Sugar provides nice platform agnostic classes that (hopefully) will look nothing like Delphi’s, but are just well designed APIs that work well. Sugar.Legacy bulds n top of Sugar to provide RTL/VCL compatible classes (mapped or real), such as TStringList and functions such as copy(), DateTimeToStr(), etc.
re FPC: check what their license is. it might be GPL.
FPC license is modified GPL, so it allows linking with any app AFAIK. But compiler itself and RTL is GPL, so Sugar maybe can use it - due to open source license!)
No, if the FPC RTL license is gpl, we absolutely cannot touch it for Sugar.
IMHO, now we have FPC-codebase, so some RTL ideas can come from FPC sources.But personally, I did not think that it will be useful to directly port any Pascal-based sources. Sugar ability to rely on platform-native RTL via mapping must be used instead pure-pascal codebase.
Be carefoul, remember many code inside FPC was borrowed from Delphi RTL. While that is supposed to be cleaned in the past, i dont know of any person checking this was true.
Now i m thinking that best scenario will be to complete rewrite of RTL using mapping techniques. Nobody else uses mapping due to obviouse reasons)
So, trying to use native platform classes as low-level stuff will help avoid none-portable asm-level perfomance tuning.