Is this considered as project risk or project issue?

Actually, you have BOTH an issue and a risk. The issue you have is closely related to the risk, but they are not quite the same.

To clarify this, you have to look at the PMBOK® Guide's definitions of issue and risk:

Issue - a current condition or situation that may have an impact on the project objectives.

Risk - an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Issues and Risks are similar in that they may affect project objectives. They are different in that issues are CURRENT conditions or situations, while risks are UNCERTAIN events or conditions. An issue is something that has happened, or is happening. A risk is something that might happen.

You have an overloaded engineer. That's an issue. It's current, and it may affect project objectives. It needs to be added to the issue log, and assigned to someone to deal with it.

Your overloaded engineer might not deliver on time. That's a risk. It may or may not happen, but if it does, it has an effect on project objectives. (Assuming that late delivery of this engineer's work will indeed affect project outcomes, which it might not if it's not on the critical path.) It should be added to the risk register, prioritized using qualitative risk analysis, risk responses planned, and assigned to someone.

This issue and risk are closely related, and have the same root cause, and should probably both be assigned to the same person. You will at least need to coordinate them, and you may want to manage them together using just risk management (which provides more tools & techniques for managing them), and use the issue log simply to keep a record of the occurrence.

Also note that the PMBOK® Guide (p.96) describes the issue log saying "Throughout the life cycle of a project, the project manager will normally face problems, gaps, inconsistencies, or conflicts that occur unexpectedly and that require some action so they do not impact the project performance."

Notice that these are things that occur UNEXPECTEDLY, meaning that they were not identified risks. At a minimum, this means that the issue log includes items that were not identified as risks, and so did not go through risk analysis & response planning.

Some may argue that risks that occur don't belong in the issue log because they were expected, and are being managed in the risk register. Personally, I like to have them in issue log in order to have a single place that lists all current situations, whether expected or unexpected.

Actually, you have BOTH an issue and a risk. The issue you have is closely related to the risk, but they are not quite the same.

To clarify this, you have to look at the PMBOK® Guide's definitions of issue and risk:

Issue - a current condition or situation that may have an impact on the project objectives.

Risk - an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Issues and Risks are similar in that they may affect project objectives. They are different in that issues are CURRENT conditions or situations, while risks are UNCERTAIN events or conditions. An issue is something that has happened, or is happening. A risk is something that might happen.

You have an overloaded engineer. That's an issue. It's current, and it may affect project objectives. It needs to be added to the issue log, and assigned to someone to deal with it.

Your overloaded engineer might not deliver on time. That's a risk. It may or may not happen, but if it does, it has an effect on project objectives. (Assuming that late delivery of this engineer's work will indeed affect project outcomes, which it might not if it's not on the critical path.) It should be added to the risk register, prioritized using qualitative risk analysis, risk responses planned, and assigned to someone.

This issue and risk are closely related, and have the same root cause, and should probably both be assigned to the same person. You will at least need to coordinate them, and you may want to manage them together using just risk management (which provides more tools & techniques for managing them), and use the issue log simply to keep a record of the occurrence.

Also note that the PMBOK® Guide (p.96) describes the issue log saying "Throughout the life cycle of a project, the project manager will normally face problems, gaps, inconsistencies, or conflicts that occur unexpectedly and that require some action so they do not impact the project performance."

Notice that these are things that occur UNEXPECTEDLY, meaning that they were not identified risks. At a minimum, this means that the issue log includes items that were not identified as risks, and so did not go through risk analysis & response planning.

Some may argue that risks that occur don't belong in the issue log because they were expected, and are being managed in the risk register. Personally, I like to have them in issue log in order to have a single place that lists all current situations, whether expected or unexpected.

I believe that a risk with a contingency plan does not belong in the issue log when triggered. Your contingency plan will go in the schedule then you have planned activities that need to be managed.

Adding the trigerred risk to your issue log will mean that you cannot close the issue until resolved, in this case completing all contingency plan actions. My goal is to resolve issues as quickly as possible, not leave them on the issue log as a memory jogger.

I think the new definition of issue in the sixth edition of the PMBOK Guide is unfortunate. If you take it literally, you will have an awful lot of issues in your issue log. The problem with the definition is the word "may".

The butterfly beating its wings on the other side of the planet may impact your project objectives.

I believe that a risk with a contingency plan does not belong in the issue log when triggered. Your contingency plan will go in the schedule then you have planned activities that need to be managed.

Adding the trigerred risk to your issue log will mean that you cannot close the issue until resolved, in this case completing all contingency plan actions. My goal is to resolve issues as quickly as possible, not leave them on the issue log as a memory jogger.

We use a system where we would still include the issue because we show the sequence of steps that will be used to reduce the consequence level. Although the approved actions themselves get entered into the schedule, it is helpful to show leadership how Step 1 reduces it from a consequence of 5 to a 4, Step 2 down to a 3, etc. It's a good communication tool to show how we are managing it rather than it just disappears from the system once it is committed to the schedule, and we may be told to stop at Step 2, and we will accept the consequences.

Everything should be evaluated within the context of your project. As you yourself summarized, the "issue" of A being overloaded belongs to someone else. It is only a risk on your project.

This can be difficult to assess for both risks and issues. At the end of the day, you have to ask yourself: "what project outcome is impacted by the issue or risk?" If you can't answer the question, it's not your risk or your issue.

For both issues and risks, I like to include a status that includes multiple states, such as Needs Attention, Under Control, Closed. This way, you know which items need more management planning, which ones just need monitoring, and which ones are no longer a concern.