MF Connect doesn't support Move. So, this isn;t a Move 'Defect'. (though I'd agree that it is a poor design)

>>The bug is newly created in ALM with its new Jira-Id and the "old" one in ALM stays in zombi mode. How can i prevent that?

There is a way to work around this, but it involves manual intervention.

If a user decides to move a bug across jira projects, they first notify you.

At this, you

a) stop the connection.

b) have the jira user move the bug across projects in jira (this produces a new jira key)

c) export the cross references for the connection.

d)   remove the 'old' cross-reference pair (see the 'removes' syntax) {old jira issue key, existing alm/qc defect id}

e) add the 'new' cross-reference pair (see the 'adds' syntax) {new jira issue key, existing alm/qc defect id}

Manage cross references (microfocus.com)

>>Is it meaningful to use only one board with bugs from both projects?

no, we absolutely discourage that anyhow...

Prepare Jira for synchronization (microfocus.com)

a)  mixing projects across a joint board introduces it's own set of problems.

b) even if you could get it to work, it wouldn't tackle the underlying cross reference issue, the new alm/qc defect would still end up being created, the old one left orphaned.

the root cause of the issue is that mf connect uses jira issue keys (not id's) to track cross reference relationships in its private internal database.

take care

anil