I just got reminded that I hadn't responded to the actual points Marcus 
was making, so here we go:
> We have hidden references to FFI left over in
>
>  -> SpecialObjectArray
>  -> Compiler
>  -> the unload method itself.
>
> all of them are hacked to use the "Smalltalk at: #ExternalStructure" 
> hack to not leave references the system knows about, but of course, 
> it leaved references nevertheless of the kind that is un-tracable,
> not documented, and easily overlooked.

If you think that this is a blocking criteria for unloading the FFI, you 
should point that out and we should have a discussion about how to deal 
with situations like those. Saying that any such occurrence means the 
package cannot possibly be removed is certainly not a good answer. 
Nowadays, and assuming some of the upcoming VM changes, all of these can 
be solved in pretty decent ways:

a) With the latest VM changes, these classes can be stored directly in 
the FFI plugin and don't need to be splObjs. This is on my TODO list as 
soon as we have VMs that support it.

b) The Compiler could have class variable where an FFI extension can be 
stored (which means that another implementation of the FFI could hook 
into the compiler as well)

c) The method #discardFFI should be removed alltogether.

Of the above a) and b) may go a bit too far for 3.9 but at least I'd 
like to have a discussion about available options. Personally, I don't 
think that these references are really *that* problematic, but I'm open 
for contrary arguments.

> What happens when we load FFI? Does is call the specialObject 
> registration?

While I don't see how this question relates to unloading the FFI, the 
obvious answer is: Yes, it does. If it doesn't, you file a bug report 
and I'll fix it.

> If we then clean up the image further, do we just delete the 
> discardFFI method and loose the ability to unload FFI?

Again, I fail to see the relevance of that question for the problem at 
hand, but again the obvious answer is: No you don't. If you do, you file 
a bug report and I'll fix it.

> Will we "clean" the compiler and the specialObject
> array at some point by accident?

By accident? How exactly do you imagine that to happen? The only way I 
could see that happen is by someone making pretty explicit and 
deliberate changes. I have never seen code "just vanishing".

> Where are those dependencies documented?

Where would you like them to be documented? If that is a criteria for 
removal, just let me know and I'll fix it.

> I can do it now in the hackish way (leaving the non-tracable bits of 
> FFI), but I wasted another hour(!) for this!!!
>
> I want to stop. I don't care anymore. I want to finish.

And why in the lord's name did you waste an hour instead of spending 
five minutes writing me an email saying "hey, I've got this and that 
problem, got any ideas"? It strikes me as the obvious thing to do, in 
particular because your complaining to Stef of all people won't change a 
single thing. If you want a resolution you should talk to the maintainer.

That would be me.

Cheers,
   - Andreas