Additional Comment:

Prior to Kate-update 22.04.0 an entry (file link) could be opened/closed any number of times. 
For me it makes no sense to have a list where an entry (file link) can be opened only once per session 
(often I open/close a file or files multiple times per Kate session if a new code change is necessary...)

I'm not seeing the greyed out thing. I see something similar: once I open a file in Kate, either with the open file dialog or the open recent menu, I can't use the open recent menu again to focus or re-open it. 

I'm seeing this in Kate 22.04 and in HEAD (commit e22bd530f273ae0097ec47d9a004c60f3cbf597a).

Update:

Today I removed all settings and personal data from this two local folders

/home/*USER*/.config/kate/
/home/*USER*/.local/share/kate/ 

in order to test if I had some kind of mistake or wrong setting in there (etc.).

But no, nothing changed: Kate still allows entries (file links) in the Recent File List to be opened only once 
and then sets the menu to empty (grays it out). This "bug" (if it is one) is not a major one, but makes my
work a little bit tiresome as I have to close/reopen Kate in order to have access to the Recent File List...

I'm 100 % sure that this behaviour did't exist prior the the last Kate update (I did it on the 14 May of 2022).
At this point I cannot tell if it is a special problem with Kate + Manjaro or a general one with every KDE distro.

Thank you, best regards.
Chris K. from Germany

Update II:

I just tested the function "New Session (Alt+S)" in order to restart Kate automatically without closing it.  The result is "funny": All entries/links in my Recent File List which were clicked one time in my last session are left in the Recent File List  when I click "New Session (Alt+S)". 

In detail: If I had two links/entries in my last Recent File List, the next time I start a "New Session" I will have four links:

-> two duplicated links at the top which are clickable (only once)
-> two dead links at the bottom, which are not openable (dead)

If I click at the two entries/links at the top, my Recent File List is set to empty and grayed out (the two old links at the bottom are dead as I mentioned above).  If I then click on "New Session (Alt+S), two new links will be added to the Recent File List at the top while now four dead links are still visible. This game can be played into infinity: If I click on the two new entries on the top, the list will be grayed out; a "New Session" will then show six/eight/ten/12/14/...n+2 dead links in the Recent File List an two new clickable links. 

My current, very simple Recent File List with only two entries looked like this (two css-files from my Vivaldi Browser):

cplove.css      (clickable)
common.css  (clickable)
cplove.css      (dead, from previous session)
common.css  (dead, from previous session)
cplove.css      (dead, from previous-previous session)
common.css  (dead, from previous-previous session)
cplove.css      (dead, from previous-previous-previous session)
common.css  (dead, from previous-previous-previous session)
cplove.css      (dead, from previous-previous-previous-previous session)
common.css  (dead, from previous-previous-previous-previous session)

Thank you, best regards.
Chris K. from Germany

So, from reading the source code with naive eyes that haven't seen much Qt/KDE code.

Recent files are managed with a KRecentFilesAction (subclass of KSelectAction, itself a subclass of QWidgetAction, itself a subclass of QAction) object stored in the m_fileOpenRecent member of KateMainWindow. This object is initialized using inline/template function KStandardAction::openRecent. 

    m_fileOpenRecent = KStandardAction::openRecent(m_viewManager, SLOT(openUrl(QUrl)), this);

I've noticed that KateMainWindow has a slotOpenDocument slot, that isn't used anywhere. This one calls m_viewManager->openUrl(url, QString(), true);. It seems like it should be used in the previous line instead of calling directly KateViewManager::openUrl like this:

    m_fileOpenRecent = KStandardAction::openRecent(this, &KateMainWindow::slotOpenDocument, this);

Anyway, I tried and it does not fix the issue. Slot openUrl of KateViewManager (m_viewManager) is supposed to be called when KRecentFilesAction's urlSelected signal is emitted. This happens in KRecentFilesActionPrivate::urlSelected, a function called when signal KSelectAction::triggered is  emitted.

It lead me to explore KRecentFileAction's code, and in particular its addUrl where the problem seem to happen.

More specifically:

    using Info = KRecentFilesActionPrivate::RecentActionInfo;
    // Reverse iterators because the most recent actions are at the end of m_recentActions
    auto it = std::find_if(d->m_recentActions.rbegin(), d->m_recentActions.rend(), [&url](const Info &info) {
        return info.url == url;
    });

    if (it != d->m_recentActions.rend()) { // url already has an action in the menu
        // Remove the action...
        QAction *act = removeAction(it->action);
        // ... move the relevant object to the end of m_recentActions
        std::rotate(d->m_recentActions.rbegin(), it, it + 1);
        // ... prepend the action to the menu
        menu()->insertAction(menu()->actions().value(0), act);
        return; // All done
    }

If the URL is already in the menu, it moves it around by removing the associated action, and reinserting the action. But reinserting the action does not seem to work (anymore?). At this point, I suspect a bug in Qt, or a method should be called to make the action work again. But I repeat, I didn't know QAction before yesterday.

This version of the code works:

    auto it = d->findByUrl(url);

    if (it != d->m_recentActions.cend()) {
        // Remove the action...
        delete removeAction(it->action);
        d->m_recentActions.erase(it);
        addUrl(url, name);
        return; // All done
    }

It recreates the action from scratch. I'd also suggest defining a removeAction method that takes the iterator and calls erase automatically because this is what is done everywhere in this file. I'll submit a patch.

There's still a bug somewhere, so someone more experimented than me may want to investigate why reusing the action does not work.

Fix here: https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/142

Nate, this bug might be a 15-Minute Bug.