AWS elastic load balancer stickiness didn't update with CloudFormation

Question

I had an AWS CloudFormation template for ECS with an elastic load balancer with sticky sessions turned on:

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: true
        - Key: stickiness.type
          Value: lb_cookie

I changed the back-end to be stateless, and updated the CloudFormation template by simply deleting the TargetGroupAttributes section.

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: true
        - Key: stickiness.type
          Value: lb_cookie

After all, the TargetGroupAttributes section is optional, and stickiness.enabled defaults to false.

But after I redeployed the CloudFormation template, increasing minimum number of desired instances as a test, the number of instances went up but refreshing a page got the same instance each time. Sure enough, in the console if I edit the target group attributes, it shows "Stickiness" is still turned on!

I thought CloudFormation was supposed to be smart enough to determine the effective settings, then calculate the delta (the "change set"), and make changes as needed? Did removing TargetGroupAttributes altogether confuse CloudFormation, or did I make a mistake somewhere? Will I have to add back the TargetGroupAttributes and explicitly set stickiness.enabled to false in order for CloudFormation to figure out it needs to change something?

Update: Sure enough, I added back the TargetGroupAttributes section with stickiness.enabled explicitly turned off:

  WebTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties: 
      …
      Port: 80
      Protocol: HTTP
      TargetGroupAttributes:
        - Key: stickiness.enabled
          Value: false

This was sufficient to turn off stickiness.

From a developer's viewpoint, I would suspect that CloudFormation, creating its graph of settings, didn't even include the TargetGroupAttributes section, so therefore it didn't compare the old TargetGroupAttributes subgraph for any changes. (But this is an obvious gotcha for graph comparison and splicing. It should be accounted for in the algorithm.)

Is this known and documented behavior, or should I file a bug ticket?

Update: I filed CloudFormation CLI Issue #992.