asterisk users - Mar 2017 - AMI ManagerAction UpdateConfig on file with #include may corrupt the file

I have seen the following scenario that may lead to a corrupted and possibly
invalid configuration file after using UpdateConfig through AMI, at least with
Asterisk 11.25:

There is a configuration file a.conf that contains several sections and also
contains a #include "b.conf", which defines a few sections of its own.
Both files a.conf and b.conf start out syntactically valid and with no duplicate
categories between the two
files.

An AMI client requests a category listing (ListCategories) from a.conf . The
listing of categories is returned, including the ones defined in b.conf. There
is no indication in the answer about the true source of the categories.

The AMI client attempts to use UpdateConfig with the set of actions EmptyCat,
followed by a few Append to define new variables. The intent is to complete
replace the content of the category with a new set of variables. It happens that
the chosen category
is actually defined in b.conf.

The actual result is that b.conf is left unmodified, and the variables that were
supposed to go in the emptied category are instead prepended to the #include
"b.conf" statement, without the [category] delimiter that starts a new
category. This
syntactically places the variables as a content of whatever section was before
the #include, and if the #include happens to appear as the first line of the
file a.conf, it leads to variables outside of any category, leading to an
invalid configuration file.

Is there a way to prevent this scenario, without actually going to the
filesystem and trying my hand at parsing the configuration file for any
#include's that might be the true source of the categories I want to update?
For the sake of argument, my AMI
client runs on a different machine, so direct filesystem access is nontrivial.