hardware device that use [...]
Well,... maybe not that ambitious. :-)
The big difference between 9 and 8 right now as regards rasters is that 9 has huge, more powerful infrastructure than 8, but you have to build what you want out of that infrastructure, while 8 has many more packaged features done for you in rasters within what is a more constrained infrastructure.
Short term, right now with rasters you can do more with 8 easier. Long term, there is no comparison because when 8 tops out that's it, while 9 doesn't top out. Within months it will be a case where 9 will do more packaged stuff than 8 with rasters as well as having better infrastructure.
To take Surface Tools as an example, in 8 you have the surface transform dialog which allows construction of expressions to operate on surfaces using a defined set of functions. That's a very good idea, and there is an impressive set of functions available in that dialog, many of which accomplish in one function what would require a chain of simpler building blocks within 9. But those building blocks within 9 have a way more infinite applicability and won't slow down to a halt with bigger data, or at least nowhere near as quickly as the infrastructure in 8.
There is also the innate flexibility. Don't kid yourself: what you are doing when using that surface transform dialog is you are writing a program. It is a fair question, therefore, just what kind of programming environment does the surface transform dialog provide, and how does that environment compare to 9.
Without doubt that dialog is a much more constrained environment than 9. 8 is very good - I'm very proud of the work we did in 8 - and it is a better programming environment, as far as I can tell, than other classic GIS for such things. After all, 8 has spatial SQL and neat things like the surface transform dialog in it. But compared to 8, 9 really hits it out of the park as a more sophisticated, more powerful, more general, and overall a much better programming environment. The experience of 8 made that possible.
For all that while 8 may have a more constrained infrastructure, for people who want point and click capability (a great thing, in my book), 8 has years of accumulated, packaged dialogs and functions. They may top out way sooner than 9 in terms of capacity, but there's lots of them and they work great. 9 doesn't have those yet, so while, sure, you can get down to it and roll your own by recombining what 9 does provide, that's often not at all realistic for most nor is it desirable.
When I mentioned applying 9 infrastructure I had in mind what most uses for the surface transform dialog historically have been: relatively straightforward applications of comparisons and manipulations between rasters. Those are cases where not being constrained by an expression within the specific rules of a one-of-a-kind dialog, and instead being able to use a full and very rich SQL, that can also tap into an even more rich scripting environment, are a good example of how the better infrastructure in 9 can work for you.
Setting out to duplicate very big and complex, multi-step packaged dialogs like starting with vector point clouds, creating an intermediate interpolated raster surface, computing raster contours on those in the usual way, and then vectorizing them is a very different kettle of fish. That you could do such stuff given skill and effort in 9 is impressive. It shouldn't be a surprise, because, after all when Manifold's engineering staff adds such capabilities to 9 that's what they will be using: 9 itself. But whether you should do such things as opposed to just letting those features appear in point and click fashion is a different question.
My advice is to start simpler if this interests you, since there is little point other than intellectual interest in starting on a feature that Manifold likely will introduce before you get it done. The focus in 9 clearly is to bring all vector operations to a reasonably complete level at the current set of aspirations. That means things like adding a few more snap modes, another pass through the vector editing infrastructure and restoring the ability to manipulate curved segments that was temporarily lost in the shift from modal dialogs to non-modal panes.
In the months ahead Manifold will turn to very fully articulated implementations of everything raster under the sun. We can make it a lot easier for people by implementing automatically a pixel-based programming and UI approach, which now must be manually derived in an extra step from the tile-based storage model, and by adding a variety of common raster tasks, say as raster templates, for things like watersheds, viewsheds, contours, and the like. Like I said, all that is implemented using 9 itself so in theory anybody could do it right now, but in practice it is easier to let Manifold do it for you. Besides a probably greater familiarity with the product the Engineering staff has the advantage that if they ever see the opportunity to add a helper function that eliminates the need for some very roundabout approach, well, they can add that function.
The good news about rasters, by the way, that raster features tend to be very easy and often (not always, but often) are completely obvious how to parallelize. So it's possible to implement very many of them very quickly. :-)