User Mode Traps
On most existing architectures, a trap results in a mode switch, a jump to the kernel's interrupt handler. For a lot of these jumps, the kernel just raises a signal in the userspace process. For dynamic languages, it would be useful if the traps only caused an unconditional jump and no mode (or context) switch. An example would be an integer overflow or a floating-point exception. The first of these examples is typically handled by promoting the values to big integer objects and retrying the operation. Even things like memory-protection failures would be useful for implementing better garbage collection and distributed objects.
Related to this issue is the idea of having traps rather than condition flags for rare things. Some architectures have condition flags for integer overflows. These flags can be tested in userspace, but that results in a conditional branch after every integer operation in Smalltalk, which is expensive in terms of instruction cache usage. Since these conditions are exceptional, they should be handled in a way appropriate to their rarity.