Even though I mention "optimizations" in the latest beta, they are all fairly small.
The multiply probably offers the biggest improvement and that's mostly due to the fact that it loops... a lot.  Some of the optimizations only save a handful of clock cycles, but they also save a few bytes which are just as important.

The more time I spend in the math library, the more apparent it is that floating point needs to be avoided as much as possible, which would require a redesign of BASIC.  Any significant improvement may not be an option in 8K.

And there some things just can't be fixed in software.  The 6803 can do a lot of things fast, but it has some significant limitations.  Much of the math library depends on operators that directly modify memory for manipulation of the floating point registers.  Even though the floating point registers are located on the direct page, many 6803 instructions don't have support of direct addressing.  The most significant of these are ROL, ROR, INC, and DEC.  This means that every time one of these opcodes is used, it requires an extra byte to store the address, and an extra clock cycle to read that byte.  I would not be too surprised to find 50-100 bytes of additional ROM have been used just to store the zeros of these addresses.  It also means there are a lot of wasted clock cycles.  The 6803 also lacks many important opcodes for dealing with the 16 bit D register.  The missing add carry D, subtract carry D, rotate left D, rotate right D, and compare D, would make several more optimizations possible.

Math library aside, there are still many other optimizations related to strings, memory moves, and basic interpreter functionality that haven't been put in the 2.1B version.  Once everything is in, a program that performs a lot of string manipulation, and comparisons is more likely to see a noticeable speed increase than something that depends on math.  I just don't know if there is enough room for everything without dumping something like the CONTROL-key token entry system.  Dumping that and the graphics entry saves about 100 bytes, but I don't want to dump it unless I have to.

I still have to debug the code that saves the next line pointer, and uses it to advance to the next line.  It will make the biggest difference on code that uses ELSE since it is more likely to skip the remainder of the line.