I think forking, versioning and packaging are being mixed up here.
There will always be an element of customisation by device manufacturers. Whether it's stuff like adding or customising apps and themes for differentiation or necessary things like adding drivers and base-port code optimised for their particular hardware and peripherals.
I think what is important though is that compatibility for 3rd party software (be it apps or lower-level plug-ins) is maintained. That is normally the case though - a Symbian^3 app should be able to run on any Symbian^3 device for instance (as should any Symbian^1 or Symbian^2 app). Typically you'd expect the app to continue working on Symbian^4, ^5 etc. devices. However Symbian^4's switch to the new Qt-based API will most likely break compatibility for apps - but that's a very special case though (and I'm convinced it's for the greater good) and will not happen often.
This is just normal versioning though. It's no different to what you see on PCs (Windows2000 -> XP -> Vista -> 7) or Macs (Mac OS 9, OS X, OS X 10.2, 10.3, 10.4 etc) and has nothing to do with forking.
Linux is a bit more complicated though. Windows and Mac OS X are sold a single product that combines the low-level OS kernel, libraries, middleware etc. with a UI and a selection of apps. To most people, the combination of all that stuff is "the OS". Linux (strictly speaking) is just a kernel. To get a full-blown desktop environment you need to add a load of stuff on top. For many of the required bits and pieces there are several competing projects and/or products. What distros like Ubuntu, RedHat etc. do is take a bunch of these pieces, put them together and package it all up nicely. To the end user the distros may effectively seem like different OSes but this is still not forking. It's just different combinations of stuff.
(Pre-foundation Symbian OS was somewhat similar: Symbian OS was kernel and middleware without a UI. S60 was Symbian OS + a UI. UIQ was Symbian OS + a different UI. Similarly for MOAP, Series90, Series80 etc.. Now that S60 + Symbian OS have been combined into the "Symbian Platform" I guess it'll be closer to the Windows or Mac OS X model in future)
Forking is when people working on a software project can't agree on how to progress it and therefore each take a copy of the code and continue developing it their way. If the differences are big enough the forks will drift apart and end up as completely separate projects. (In some cases though they can reconcile their differences and merge the forks back together)
If that happened across the whole of Symbian, that would undoubtedly suck. However, the chances of that are minimal. Software, especially big software like an operating system isn't just one massive blob of code - it's typically broken down into distinct modules. Often those modules will be isolated from each other such that they can (mostly) be developed (or even replaced) independently.
In the case of Symbian, the breakdown is done at several levels: layers, packages, collections and components (see the recent System Model video on the Symbian Blog if you want to know more). There are rules and restrictions on how these elements interact with one another.
If anything, I would have thought that forking at the component or perhaps even package level is more likely. It's the package owners' job to try and avoid this, but even if it did come to, say, a package forking it wouldn't necessarily be disastrous because it should be fairly well insulated from the rest of the OS.