Hmmm.... another case of not having read the documentation.
From the documentation for the CFSETTING tag:
If you nest cfsetting tags: to make HTML output visible, you must match each enableCFoutputOnly = "Yes" statement with an enableCFoutputOnly = "No" statement. For example, after five enableCFoutputOnly = "Yes" statements, to enable HTML output, you must have five corresponding enableCFoutputOnly = "No" statements.
That explains why I'd been finding cfsetting "unreliable" for the purpose of setting the EnableCFOutputOnly flag, because I'd always assumed it was just an on/off thing. It also means I'll have to go back through the framework and find the places where I've used it, for example, the cf_html tag now automatically un-sets the EnableCFOutputOnly flag to eliminate the need to nest cfoutput tags in every cf_html instance, even when no variables are being used, which is something I used to do to ensure that the code wouldn't break if someone put cfoutputonly in their applicatin / onRequestStart. I'm pretty certain this will result in a new function:
<cfargument name="enable" type="boolean" required="false" default="true" />
<cfargument name="repeat" type="numeric" required="false" default="1" />
<cfloop index="repeat" from="#repeat#" to="1" step="-1">
<cfsetting enablecfoutputonly="true" />
<cfreturn 0 />
<cfset repeat = -1 />
<cfset enable = true />
<cfset repeat = repeat + 1 />
<cfset enable = len(enable) />
<cfreturn repeat />
update: (later the same day) -- yeah, I saw this coming... it can't be a function, because it starts a new output buffer when it enters the function, which circumvents the enablecfoutputonly setting. So I just uploaded a new build with a custom tag that does this instead.