(I double-clicked something .....)

This situation exists for all version of krita from 4.1.7 onwards.

When File-A.kra is opened and then Saved As File-B.kra, the internal folder name (File-A) is not updated. This causes confusion when forks of an image are made for development purposes because krita gives advisory warnings (when Closing a changed image) such as "The document 'File-A' has been modified." but the image tab has the title "File-B.kra"

Similarly, it's to be expected that people will make OS level copies of .kra files and rename them for whatever purpose. In this case, a Save operation ought to rename the .kra file internal folder to match the file name.

Um... The internal folder name is the image name defined in document properties. Krita has never associated the internal folder name with the file name apart from on document creation.

Thanks for the rapid reply Boud. I've found it in File -> Document Information and I can change it if I want to.

It would be much more convenient if it was automatic so can this report be changed to a 'Wishlist' category? (I don't think I can change that myself.)
If not then I can make it Resolved (or you can).

True, I can confirm (but I get used to this behavior since long time; minor for me).

That's because Krita has a "document name" since a long time with a "Title" (the one you probably name ".kra file internal folder name"?). The "Title" is not equal to the "File name" (the one you save, save as with extension). 

The confusing part is that Krita autogenerate the "Title" from the first "File name" (without extension), but then this generated "Title" is never updated, even if the "File name" changes (eg. File rename, Save As) and the "Title" keeps the same for many forked documents. I saw it many time, when designing playing cards, series of illustrations, tokkens for board games, book cover. Because on this workflow you often do one, then fork it for all other one. (copy/paste quick forking + Save As, to avoid the longer creation of a template)

What behavior would you prefer? Here I know I would prefer Krita to only communicate with me using the "File Name" everywhere in dialogs and title bars. That would be my request too as I never used "Title", but probably other user does?...

So, +1 for the "wish" item.

For me too, I would prefer Krita to only communicate with me using the "File Name" everywhere in dialogs and title bars.
This would probably be an easier change than auto-updating the Title. It would give a good match to the image tab name with multiple images open, which is my 'problem' with it at the moment.

It's an ancient holdover from when a .kra file could contain more than one filename.

I've changed the title of this report to better indicate what the problem is, in terms of how it affects a user.

Another, more complicated, solution would be to implement my suggestion about updating the Document Title on Save or Save As with this behaviour selected as a non-default option, maybe in the Settings -> Configure Krita -> General -> File handling. This would take care of the situation where anyone uses the Document Title for their own purposes at the moment.

After David Revoy's comment, I've set this to Confirmed but I can understand if it was set to an Importance of 'wishlist'

@Ahab Greybeard: From a user P.O.V; I'm seing here a simplier logic than adding a new config option:

* In first place, prevent Krita from generating a "Title" after a first save (leave the "Title" field empty).
* If the field "Title" is empty → communicate to users only using the "File name".
* If field "Title" contains something → use that.

That should help at protecting the feature "Title" and its userbase; while simplifying life of those who don't use it.

@David Revoy: That is simpler and would suit me from my personal P.O.V.

However, at the moment, the Title is stored as the internal folder name inside the .kra file and that has to have a name of some kind. So the .kra file would need an internal indicator to say if the name was given by assignment of a Title or by some other means. Or some other solution.

It gets more complicated the more you look at it.

I tried to look into this today, but it is extremely tricky because it touches the file format itself, and keeping everything compatible with older files is pretty tricky. I'm not sure I actually dare change this.

Hi Boud, thank you for looking into this issue and I totally understand it doesn't worth breaking retro-compatibility for fixing a label on a dialog. If it is part of the architecture of *.kra; let's keep it.

( Changing Title in File -> Document Information is a good workaround for *.kra project that need to be perfect clean. )

As David says, there is a workaround and as Boud implies, changing anything could cause problems.
Setting to Resolved Intentional.

*** Bug 414380 has been marked as a duplicate of this bug. ***