Thanks for the sample file, Egor. That helps a lot. Using AI 27.4.1, the Free Transform tool and Bounding Box widgets both have some issues. The BBAccumRotation tags (and matching dictionary entries) must all be the same in order for it to recognize the rotation. If the compound and its children have no tags at all, they can be created at the same time when rotating them using these tools, and then it works. When objects are rotated, the rotation settings are adjusted individually with each one's compound rotation, which means that if they start with different rotations they'll continue to have different rotations. If you rotate any of the paths before combining them into a compound, you'll probably have this problem.

Adobe Illustrator has had some weird behavior regarding rotations long before AI 2023, which may compound what's happening here. As objects are rotated, metadata is stored in the objects' dictionaries that track their accumulated rotation. This metadata can be read with Adobe's developer SDK. In a compound path, for example, these dictionaries exist for each of the paths as well as for the compound object that contains them. The same is true for groups, effects, etc.

When you rotate a group or compound path using the Rotate too, that rotation metadata does not get applied to a parent container object, only to the art objects they contain.

When you rotate a *compound path* with the bounding box, it does add the metadata to the parent container. That is not true for groups, however.

Only Adobe's engineers know for sure, but it appears that the Bounding Box does not honor the accumulated rotation info it added to a compound container object. Instead, for groups and compounds it seems to parse each selected object within the group and honors a common rotation that all of them share, or else reverts to no rotation if rotations are mixed.

Reset Bounding Box often doesn't seem to work for me, or gets applied only after changing the selection. It's crazy even without new bugs.

I just double clicked on the compound path and set each child to 0. It's not a fix either since I'm rotating each Compoundpath childs individually and will end up with a slightly different Compoundpath.

Yep, Fredde, this seems like a reason behind it for sure.
Ai though just doesn’t provide a native way to reset the rotation of child paths (and actually it is not a proper solution, since we might need that data)
The naive solution is just to hit Pathfinder Add button, but it not just kills the data for children, but also moves the starting points and change directions sometimes (hence the arrowheads I applied). And sure one would have to repeat it for every child, which is again a better job for a script... and why use it then, when there is a better-but-not-perfect workaround? :)

BTW, if you want to share the script you use to fix it, for others to use it, please put it directly in a comment, or rename the file to .txt, since UV blocks attaching .js/jsx files.

Another thing I noticed. If I go into the Faulty Compound Path and set the two paths inside it rotation to "0". Then the bounding box behaves normally again.

I don't know if this means anything at all but the two objects have different rotational data if you look at the compound path itself, and the two objects inside it.

Here is that basic test file and the recording

Something to note I found about this bug, is it seems to be some hidden setting or preference. When I opened an old project to test if this bug/hidden feature is per project or per program. I found the behavior now seems to be on at least the two projects I have tested this on, another thing to note is in the properties tab the degrees of the object seem to be automatically set to 0.
found a solution, seems to only affect groups of objects when one object has an orientation differing from the rest of the group

I have another example of this bug and am including a test file as requested.
You'll see that the bounding box resets every time a (rotational) transformation occurs, and the individual components suffer the same issue even after ungrouping the object. *BUT* the bounding box of a different object in the same file *DOES NOT* reset and behaves normally, inferring that this isn't a bug that is specific to a version of Illustrator or even a file. I am currently running CC 26.5 on an iMac OS Monterey 12.3.1.

@Egor, sounds reasonable to have some customisation, maybe the traditional "have an option for legacy area type transform controls" way.

Though the main issue with resetting object-associated bounding box is more disturbing.

@Egor — it's interesting that you mention giving the user the ability to change the behavior. In the Procreate app, each bounding box has two handles, one controls rotation, and the other rotates the bounding box itself. In Illustrator, this could be achieved if there was a small lock / unlock icon attached to the bounding box. There is already precedence for this visually in how InDesign has the little box for linking text containers together.

Agree, cases differ. Let’s stick to 'Ai should allow to customize the behaviour' — and make it consistent across tools. What do you say about this approach? Is it OK to have all the tools behave the same for this, or does it make sense for some to always work with text or container?

@Egor, well, i guess it's debatable whether should text rotate with the box by modifiers, although i'd like to see the text as a main object so all the transformations should be applied to the text by default not to the box, and box should be treated as an independent rectangle only after selecting it specifically, with the group selection tool. But that's not the main point. Thing is, bounding box of the rectangle resets immediately after rotation (with corner modifiers). Maybe it's because "text is a main object so the bounding box stays with text" but as for me it creates more confusion than ergonomics. As i see this, area type text should rotate with its container no matter what tool does rotation. If i want to rotate container rectangle i'll select it specifically. I think it'd be better to have some kind of modifier for area type which can apply rotation only to the text leaving container intact not the other way around.

Egor — You're probably right. I guess bugs are the inherent nature of code and can't be attributed to the fault of an engineer, and it's also not possible to find every bug through quality control.

@Serge, the latest video of yours is actually an expected behaviour — 'at least for me'. This is why I use the bounding box only for area text transformations — Ai applies scaling and rotation with bbox to the path rather then the whole object, assuming this is what a user want to do.
Free Transform, Scale and Rotate, however, act on the whole object.

To make these work just like the bbox does, you have to select the path of the area text, precisely, with a Group Selection toll (this is what I often do).

But if you add another object in a selection along with an area text, even the bbox starts to scale and rotate the whole text instead of a path of it.

'Expected' here means it has some logic behind it, and users can get familiarized about it... but I agree it can be treated differently. Like with a general option to Transform Area Text perhaps, which just toggle the behaviour? Note 'Area' here, because a point type text always gets scaled and rotated.

There are some requests about it as I recall, so you might want to search for them...

Egor, while making the sample file i noticed another bug with rotating objects, at least as i perceive it (attach included). Rotating paragraph text box with rotate tool rotates the text box with the text as it supposed to. Rotating the same text box with corner modifiers rotates only the box while text inside stays horizontal and after rotation bounding box of a rectangle resets instantly. I see that as an inconsistency to say the least.

I guess, there's lots going on in object behavior after introducing basic shapes! :)

Egor, ah, i didn't realise Free transform tool could be used as main transformer =) Tho it's still technically applied to bounding box of an object. But in the end the muscle memory and work patterns are all that matters, it's very hard to change all those hard wired behaviors and create new work patterns.

Regarding coin picture — tho i couldn't find what combination of combining and compounds really makes objects behave like that as a group, i've been almost sure there's a way to make those behave normally. Sure i can simplify a lot in those objects but the way that group made is a result of some design process, and usually i tend to keep all the objects as redactable as possible to be able to easily change the design if needed. The point is, as you say, groups shouldn't behave differently in the first place and compounds shouldn't lose bbox orientation with any slightest rotation (until they made to do so)

I hope the issue could be solved. Thanks!

Responding to Egor — yes, if this happens to me again, I can be sure to save a file with the problematic object. I guess I mistakenly figured the engineers would know how their own software works and would eliminate the ability of the bounding box to become detached from the transformations of objects. The problem is that this behavior comes and goes, so I don't know when I'll experience it next, or how I can force it to happen.