Basic theory, if you have an exploit you want it to be hard to patch. The twilight hack blocking is but an end run around the hack (they check the save for the hack although they borked the check hard in the first few attempts, they do not fix the hack).
Know that whenever I mention signing it was pure luck that Nintendo messed up the implementation, without it we would probably be where the 360 is now save for GC homebrew and unless someone finds a method to factor large numbers, donates some seriously powerful computing capabilities or someone manages some social engineering type attacks we have little chance of breaking the signing.
1 - Wiiware Games ?
Entirely possible, they can however easily be updated and you have to pay for them (rental or hitting up a friend is easy enough for a disc).
2 - Gamecube Games ?
In crude terms the gamecube games run in a hypervisor mode using mios which keeps it fairly locked down, admittedly not all that much work has been done upon it but I doubt there is a good exploit in there. Also this was the basis for the tweezer attack (now fixed but as they said it only needed to be done once).
Not to mention we already have GC homebrew running and have done for longer that we have had modchips for.
3 - VC games ?
This one would be harder as VC games are usually just emulators and so we would need to find a bug in the emulation code rather than code built from the ground up. Although it is the same in theory as wiiware emulation tends to be simpler in terms of system interactions (emulator writing is hard and you tend not to play around with other stuff once it is done).
4 - Official NINTENDO Backup disc 1.31 ?
This is what gave us IOS16* although there may be more; I doubt it though as it is also a fairly simple app with very limited features.
*IOS16 was useful only because it still had the trucha bug, was signed by Nintendo and Nintendo had not updated it when they had updated all the other IOS versions (whether it was an oversight or a lack of desire to refit their fixing stations is another debate). This allowed us to install it via the "normal" wii methods (which check signing, at this point checking it properly) but now Nintendo has put a higher version out there with working signing it is only useful for those on a pre-4.0 wii.
5 - Wii System Menu update disc ? (semi-brick rescue disc)
This is not an official disc (I assume you speak of these:
http://hackmii.com/2008/05/semi-brick-fix-discs/ ) and as such needs a homebrew capable wii (one with the signing/trucha bug).
6 - Menu System 4.0 with SDCARD Access ?
This is the most hopeful but in reality we have had similar capabilities from some of the earliest menus. Not to mention they are sure to have locked it down somewhat (SD is a widely known and understood spec and anyone can have full access to the inner depths of the SD card).
[Edit] 7 - Maintenance Mode ?
This would be the the 4 directions at once thing (or y with starfall), it has been explored a bit from what I have heard but again it is a simple mode designed to run a very limited selection of software (again signed).
8 - Wiibrickblocker process ? (is it possible to use the patch mode of it to launch update or downgrade ?)
Brick blocking comes in 2 forms,
1) header tweak (this is used by the various channels, brickblocker and mod chips to prevent updates.
2) ripping the update from the disc, naturally this breaks signing and is ultimately no different to the method above as far as this is concerned.
When the wii runs it checks for a given section in the header and if it exists it then checks version numbers, if higher it triggers the update procedure.
This disc header is not signed though and so we can dupe the wii into thinking there is no update, this is all it does. Before you ask the version numbers are included in the signed section of the update so we can not just change those, homebrew methods rely on several things but as we would only have the official Nintendo method to install by in the first place......
