Including a Proxy-PO in team

From what you describe, it doesn't sound like you are introducing a Proxy Product Owner. In my experience, Proxy POs are situated between people with decision-making power about a product and people with the knowledge and skills to build the product. They may own the backlog but have no ownership of the product or the delivery of value. In your example, though, it seems like the Product Owner has ownership of the product, the accountabilities described in the Scrum Guide, and the responsibilities associated with product management.

Product management is a broad field and rarely does one person have the time and requisite knowledge to carry out all associated work. Personally, I think that this is one of the areas where the Scrum framework is extremely weak. It doesn't acknowledge the breadth and complexities of product management. Bringing in additional people to help with specific product management tasks and share the workload is often a good thing that can benefit the teams, the development organization, and the stakeholders. Nothing in the Scrum Guide prohibits a team of people to support the various product management functions. These people are also not necessarily considered Developers unless their work results in creating some aspect of a usable product Increment during the Sprint. The only rule in Scrum is that there is a sole accountable individual for work such as managing the Product Backlog, developing and communicating the Product Goal, creating and communicating the Product Backlog Items, ordering the Product Backlog Items, and ensuring that all stakeholders have visibility and transparency into the state of the Product Backlog.

Based on your description, I'm not seeing a significant risk for confusion. However, if you, the Developers, or the Product Owner think that there may be confusion, clearly specifying when the team would go to the current Product Owner first or when the team would go to the new person could be helpful. You don't need a formal RACI matrix. If the Product Owner can enumerate all the things that they do for or with the team, they can decide if they should be the primary person doing those things or if the new person should be the primary person doing them. Delegating doesn't remove the Product Owner's accountability, though.

I know a documented RACI in scrum is a contentious topic , but what else can be good and effective ways to handle this situation which are within scrum framework?

I wonder if that matrix wouldn't handle the situation so much as cover it up.

The Product Owner remains accountable for value, even if they have delegated certain responsibilities. Perhaps the RACI matrix would establish something else instead: the normalization of the real risk you have identified, and the illusion of managing it, through the auspices of a traditional management artifact.

I'd suggest that, in Scrum, a clear-eyed understanding of accountability ought to be enough.

I share @Thomas' opinion about Product Management being a complex thing.  But as he said, Scrum only states that there needs to an individual responsible for what is defined.  For me this is to help with ambiguity. That statement alleviates the "rule by committee" that so often slows down software development and important decisions.

I often work where the people that participate in the Product Owner responsibility have titles like Business Analyst, Architect, Lead Engineer, User Experience Engineer, DevOps Engineer, and many others.  Depending on the product that you are maintaining, there could be a number of disciplines that would contribute to the requirements or needs.  I have yet to see that there has been confusion in a team because of this. We ultimately know who is responsible.  But if the Product Owner has delegated some responsibilities, we trust that person will be communicating with the Product Owner. 

I can appreciate your concerns but at this point, that is all they are....your concerns.  You do not know if it will cause confusion so all of the work you are suggesting could be for naught.  I suggest that you let the Scrum Team decide if there is an issue.  That would mean that they proxy comes in and work begins.  If an issue arises, it can be discussed in Retrospectives, inspected and adaptation occurs as necessary.  Remember that as a Scrum Master, you are leading by example.

Thanks @Thomas, @Ian and @Daniel for the responses. I see the PO, who is accountable person in this case, has to make the responsibility split clear for the team. 

@Ian : Well said. However, I don't see any harm in getting things black and white, and if the RACI is making things transparent. 

@Thomas : I acknowledge that the scrum guide doesn't stop anyone having these supporting role and do respect their importance in product development. However, it is also clear that scrum guide is deliberately not explicit in defining how these roles will be accounted for. 

I see two options : The new role is a part of scrum team, bound by the working agreement, and the deliverable is estimated and delivered as part of overall commitment. 

Option 2 : Proxy supports PO externally, and the deliverable becomes a dependency. The challenge in this way is that IF the task is validation for a story/PBI, it might become an impediment in between the sprint.  Note that I am being practical here and considering people in these roles supporting multiple projects. 

I know I might not be thinking within the rules of scrum. Please help me correct my understanding.