This issue is still present in Zen Cart 1.5.5b. Here's a scenario:

A product, priced by attributes with a base price set to 0.00, includes two radio-button type attributes (Color: Red, Color: Black). Each of those attributes' prices are set as 50.00 (no price prefix) and the Discounted and Base Price flags are set.

Ensure that there are no "specials" associated with the product.

Set a SaleMaker sale for 50%, selecting Ignore Specials Price - Apply to Product Price and Replace Special from the drop-down selection that will apply to the product.

View the product on the storefront: Its price shows the salemaker price ($50.00 (struck-out), $25.00) ... but each of the attributes' prices still show the non-salemaker price of $50.00; the price when the product is placed in the cart is correct at $25.00.

The source of the issue is in the zen_get_discount_calc function, present in /includes/functions/functions_prices.php (both admin and storefront versions). Under the above scenario, the "discount_type_id" being returned is 5, taking the code down this fragment:
Code:
      case ($discount_type_id == 5):
        // No Sale and No Special
//        $sale_maker_discount = 1;
        if (!$attributes_id) {
          $sale_maker_discount = $sale_maker_discount;
        } else {
          // compute attribute amount
          if ($attributes_amount != 0) {
            if ($special_price_discount != 0) {
              $calc = ($attributes_amount * $special_price_discount);
            } else {
              $calc = $attributes_amount;
            }

            $sale_maker_discount = $calc;
          } else {
            $sale_maker_discount = $sale_maker_discount;
          }
        }
//echo 'How much 3 - ' . $qty . ' : ' . $product_id . ' : ' . $qty . ' x ' .  $attributes_amount . ' vs ' . $check_discount_qty_price . ' - ' . $sale_maker_discount . '<br />';
        break;
... and executing the highlighted portion of that code-block, essentially not applying the SaleMaker discount to the attribute's price. Part of the issue is that the $special_price_discount value (calculated earlier in that function) is set to (int)1.

There's a lot going on in that function and I don't (yet) have a proposed solution, but I do believe that this should be moved to the "Bug Reports".