It looks like the msp430 code has been compiled with IS_MP_BUILD = 1 instead of 0 which sets .on_off field to 0 by default in charger.c:

charging_disabled_state_t charging_disabled = {
	.enabled = 0,
#if IS_MP_BUILD
	.on_off  = 0 /* For MP build, default to off (no charging) */
#else 
	.on_off  = 1 /* else default to on (allow charging) */
#endif
};

There is more going on than the MP option flag for the build.
After multiple power cycles (turning off while on battery due to idle state) then powering up with application of AC. Two units power up automatically and two require the power button to be pressed. these 4 have all begun to charge the battery at least some of the time.
 One other unit where I am not cycling power has not charged at all.  So the disable charging flag for the FW build has not remained in effect.for all of the units

I compiled and checked in the text files with the default values which include the IS_MP_BUILD to zero. The CHARGING_ENABLED is defined as:
#define CHARGING_ENABLED		(charging_disabled.enabled && charging_disabled.on_off)

which means it will be always zero, since the charging_disabled.enabled is always set to zero. Not sure about the reasoning behind this definition but still searching!

The on_off gets set as part of the i2c transactions issued to the MSP430:

/*
 * i2c_do_action
 * This is where you define what happens when you receive words from the
 * host
 */
void i2c_do_action(void) {
        switch(i2c_address) {
        case I2C_KILL_REGISTER:
                if ( (i2c_transfer_buffer._u8[0] == 0xde) || IS_MP_BUILD ) {
                        i2c_got_kill_signal_ = 1;
                        i2c_close();
                }
                break;
        case I2C_BATT_CHARGE_DISABLE:
                charging_disabled.on_off = i2c_transfer_buffer._u16[0] ? 1 : 0;
                break;

Here is the explanation of this problem:
1.

Here is the explanation of this problem:
1.Bring up the Baby
2. Insert a new Battery.
3. The charge cycle that is needed to fully charge the battery does not happen.

1. Powered up my Baby with build 9022 and MSP430 firmware of 1322.
2. Enabled the SqueezeboxBabyApplet logs and set it to DEBUG
3. connected my Battery.
4. The battery is detected by my Baby.
5. It starts charging the Battery.
6. On the Baby's screen I can clearly see the image of the battery getting charged.
7. After a while the battery is fully charged.
8. The screen shows that battery is being fully charged.

After the Battery is fully charged I disconnected my Battery.
9. It is reported that there is no battery
10. The sign for battery is disappeared from the Baby's screen.

I reconnect the Battery:
11. The battery is detected by my Baby
12. It starts charging the Battery.
13. On the Baby's screen I can clearly see the image of the battery getting charged.
14. After a while the battery is fully charged.
? NOT SURE WHY IT TAKES SUCH A LONG TIME FOR THE BATTERY THAT WAS ALREADY REPORTED AS FULLY CHARGED TO GET TO FULL CHARGE! WE COULD DAMAGE THE BATTERY
Aug 10 00:06:43 squeezeplay: DEBUG  applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:759 no battery
.
.
.
Aug 10 00:06:45 squeezeplay: DEBUG  applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:787 on ac, charging
.
.
.
Aug 10 00:28:07 squeezeplay: DEBUG  applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:764 on ac, fully charged
15. The screen shows that battery is being fully charged.

Re-run the test with build 9023 from 751-rtm. Same result as before.
I noticed that if we disconnect and connect that battery immediately we provide to much charge to the Battery which could cause the Battery not detected anymore!
I had to take off the battery for it to cool off and then it was working fine.

I monitored the temperature and the voltage of the battery at the time that it was fully charged:
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
817
# cat /sys/bus/i2c/devices/1-0010/battery_voltage
13675
Then I disconnected/connected the battery. The battery gets charged again and once it hit the full charge again here is the result:
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
889
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
920
# cat /sys/bus/i2c/devices/1-0010/battery_voltage
15167
# cat /sys/bus/i2c/devices/1-0010/battery_voltage
15188
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
934
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
949
# cat /sys/bus/i2c/devices/1-0010/battery_voltage
14905
After the second full charge I get:
# cat /sys/bus/i2c/devices/1-0010/battery_voltage
14381
# cat /sys/bus/i2c/devices/1-0010/battery_temperature
1596

I disconnect the battery and reconnect it and we do not detect the battery anymore.
Wait for a while and we detect and fully charge the battery.

I would assume that the code should see the battery in all cases, and then decide to start the recharge cycle depending upon the battery/temperature readings.

It should decide to see the battery regardless of whether it reads high battery voltage and high temperature.

By Maurice:
case BATT_CHARGING:
... 
if (battery_voltage > battery_stop_charging_voltage
|| (deltaT > dTdt && holdoff_timer == 0)
|| (safety_timer == 0))
{
stop_charging(battery_cap /* fully charged */, CHARGER_COMPLETE);
break;
}
The if statement will stop charging and assumes the charge is complete as soon as the battery voltage is above 16V. A battery that has been sitting for an extended period time without being used will trigger a false positive as soon as the charger starts. A charger for NiMH should ignore a too high voltage for the first few minutes.
This could be the problem that Ryan was experiencing before and he cannot reproduce now because the batteries have been exercised.

We discovered two bugs as part of the investigation:
1. Comment 7 and 8.
2. Comment 11.

I assign this bug to Alan.

It looks like this was caused but the issue described in bug 16451

What about the bug in comments 7 and 8.

Charge termination uses dT/dt as the primary condition, with over-voltage and upper-limit temperature safety checks. These are as recommended by the battery manufacturer.

Repeated removal and re-insertion of the battery is not a typical use-case. I guess that such use could damage the battery if done to excess but I do not see that as a problem. When a battery is inserted, the controller has no means of determining the current state-of-charge other than by trying to charge it - it cannot assume that the inserted battery is the same one as was just removed.

The point in comment #9 related to the fact that the newly-inserted battery's temperature is over the limit, and it has to cool down before normal operation begins.

In conclusion, I do not see any significant issues with the current operation.