This is an incomplete roadmap of what I'd like to see in FreeSCI in the near future:
Syke (i.e. Matt Hargett) has a point about top-down work, of course ... but I am thinking that Glutton (the VM itself) should be converted last. I would rather see things like the resource manager converted first (a bottom-up approach), with Glutton coming in last. If anything in Glutton should be objectified first, it would be the segment manager (which has no direct counterpart in Sierra SCI and is therefore already abstracted from the original semantics).
Non-reliance on the kernel table (vocab.999 / 999.voc)
This resource is notoriously unreliable, and should not be used. Instead, we should use the ScummVM autodetection mechanism to choose an appropriate built-in kernel table. The other vocabulary resources are generally reliable and should be used to the extent that it makes sense.
So what are these vocabulary resources?
vocab.999 / 999.voc contains names of the kernel functions which are implemented by the interpreter. In Sierra SCI, they are used exclusively by the debugger, which is why keeping the file up to date was less important.
vocab.997 / 997.voc contains the names of every selector in the class hierarchy. Each method and property name consumes one id, but if a name is shared between classes, one id will do.
vocab.994 / 994.voc contains offsets into certain classes of certain properties. This enables the interpreter to update these properties in O(1) time which was important in the era when SCI was initially conceived. What we have previously done in FreeSCI is to simply figure out what property a certain offset refers to (which requires one to guess what class a pointer points to) and then simply use the property name and vocab.997. This results in much more readable code.
How does FreeSCI use vocab.997 ?
FreeSCI loads vocab.997 on startup, and fills in an internal structure that allows interpreter code to access these selectors via #defined macros. It does not use the file after this initial stage.
Removal of the graphics subsystem
The graphics subsystem is currently incompatible with much of the UI in SCI1 and later, and certain rooms in SCI0. It would be nice here to revert to a plain bitmap-based approach (like ScummVM). However, we want to keep the graphics subsystem around as it is well suited for SCI32; a battery of unit tests is desired to make sure that this remains possible.
Keeping Glutton around
Glutton currently has problems with strings in some games; a reimplementation is underway (by lskovlun) to rectify this. Some may think that this is a good reason to keep the VM as close to Sierra's as possible (see the recent reimplementation); but I believe that the Glutton VM (if the string fixes turn out to work) would work equally well with SCI1.1 and earlier and SCI32, whereas the reimplementation would have to do something else for SCI32.
What is this thing about SCI32?
Whereas SCI1.1 and earlier have a 64 kilobyte heap space which is addressable via pointers, SCI32 uses memory handles exclusively. That means that all the string handling functions have been replaced by a single String() call, array handling (which used to be primitives) is now a kernel call Array(), etc. Direct pointer addressing is no longer possible!