I don’t use it (I use AndroidAPS with the Dash pods) but so far as I can see from the documentation you are correct; the COB thing, which can be very, very mysterious, is not part of the Insulet algorithm.
That’s probably partly historical; Insulet have always assumed that boluses covered carbs, so if a max bolus prevents that this would cause a problem at least for the period of the carb adsorption time (which, of course, depends on the carbs).
I suggest dropping, or overriding, the max bolus for carbs. Unless you count the carb equivalent of fats and protein and eat a large meal with fat or protein the carbs will certainly go through before the insulin, (guess we could have a pizza-effect argument here) so limiting the insulin while doing the carbs doesn’t seem right to me.
AndroidAPS doesn’t handle underestimates of carbs and a bolus limit really is an underestimate. There is a spike which can take me over 180mg/dL when the rest of the time AndroidAPS keeps me in range.
The oref2 algorithm (which is what I am using) does seem to be informed by COB, but the spike is still there. oref2 seems robust to updates to carb intake; for example adding 5g during a meal because of taking extras even though the added 5g delivers no insulin because of the “missing” carbs from the start of the meal.
This is why I described it as weird; the Insulet Dash algorithm would just believe me and drop .5IU (my ratio is, indeed, 10). AndroidAPS says, “Let’s wait and see.” In it’s defense it does seem to work but I’m not sure it’s better than the Insulet, “Ok, I trust you.” algorithm in a closed loop system.
We definitely need more people like you who have used both and can comment on the relative merits of the algorithm