Things that should mentioned in the manual.

I stumbled over my second strange behavior that isn't a bug but is nowhere mentioned.

The first was that events in groups are sub-events. This should be mentioned, otherwise it could to lead to hard to find bugs.

The second is that 'set position' does not work with the tile movement. It took me some time to figure out why my sprite act so strange.

It's mentioned here: https://github.com/Scirra/Construct-bugs/issues/7426

but not in the manual.

Although it's not mentioned I just naturally understood it to be the case, when I started using tile movement I saw that it uses grid positions within its own behaviour so thought ok setting x,y is not going to work for this or is probably not a good idea instead I will use the grid position numbers.

Although it's not mentioned I just naturally understood it to be the case

The problem is that if I create a sprite I can set the position. This is not possible if the sprite is created. This is inconsistent.

If you use 'set position' in 'on start of layout' the object will move at the start to the position that is set in the Editor. I don't think that this is so obvious where the problem is.

And set position is a basic action not an extra behavior, if it doesn't work with 'Tile Movement' it could be confusing.

I am a construct fanboy, but I think the way the obstacle map for finding paths has a very strange undocumented way it assigns the uniqueness of the map. It uses the size of the map (32x32 size and 2 padding is not the same as 31x31 size with 3 padding etc) to set up different obstacle maps.

I can see why it has to save separate maps, but which map you are using for find path at any time is not clear.

The manual pretty clearly states "If different objects use different values, then the Pathfinding behavior must generate multiple obstacle grids in memory, and pathfind along them separately."

For starters, the cell border size (what I'm assuming you're talking about regarding padding), does not have any affect on the actual pathfinding grid itself at all. So if you take that out of the equation, it should be clear enough that a 32 grid size is not going to be the the same as a 31 grid size.

As for which grid used when finding a path for a particular object, its simply one that is defined by the pathfinding behavior properties that are attached to that same object.

While I'm not sure if rewriting the manual entry would help someone understand these things any more than it already does, I do think an in editor visualization sure would help a lot.