You were basically manually doing what the BIOS battery extender (i.e. battery preserving) function introduced.
If I was in your shoes, leaving it at the 90% charge limit 
accomplishes the goal of the new feature and does not seriously limit time away from a charger; that last 10% 
probably is not making as big of a difference.
TL;dr
I remember reading the article posted about the new feature and it ultimately was about getting the machine to lower its charge state for being plugged in a long time 
. While still switching out for frequent disconnects for time away from the charger.
I thought the end goal was 90% for the longest time being plugged in. I would have to go back and read the article. (After looking at it the end results was for 7+ days to limit to 85%)
I thought it was mentioned briefly that if you already had a charge limit it would respect that amount regardless the battery extender features were calling for.
I remember thinking it had to do with a conflict in the logic tree as they are separate features in the embedded controller which acts like a state machine. Thus it was easier to be setup as an OR function as opposed to another logic variant (XOR, AND, etc.) So it would be either: battery extender or charge limit. Something to the effect of:
IF charger limit is == NULL THEN battery extender
As far as the blinking lights on the charger that could be a confusion in the charging circuit and likely something that would be addressed in a future BIOS release. This might be useful to submit as a bug report on Github so Framework can investigate further. 
Thank you for letting others know what you experienced. Debugging the embedded controller (EC) would likely give more insight into what is going on; though it could be harder to sift through as it is fairly chatty with information which is a good thing to understand the state of the controller and its subsystems. 
The post from Framework: