It seems that the addition of feature_name as a request option (for analytics purposes) introduced a failing case when a filter had the key of feature_name.
I think enabling expectations would have caught this since it compares the actual versus expected load options. However, digging into it, I was not able to create a brainstem-js only failing case because the expectations kick in before the custom sync logic. If we were to push the expectations a bit further down the code path, we should be able to capture all the options presented to Backbone.sync and do a nut-and-bolts comparison.