What is the purpose of the PBI?

If you're the Product Owner, you may organize the Product Backlog the best way you think fit. If a useful overview or organizing principle is missing, put it there. If it's "somewhere else" transparency will be reduced.

Examples of organizing constructs include epics, features, and themes. The only limit is the imagination.

I try not to get caught up in naming PBIs in a certain way like epic, features

or themes. Everyone has a different interpretation om their meaning and we

often end up discussing that.

But I get caught up in the phrase: "Product Backlog refinement is the act of

breaking down and further defining Product Backlog items into smaller more

precise items.".

Then as I see it PBI's end up getting very detailed and hard to communicate.

And example could be that I want to rewrite an app from one old tech stack to

another modern tech stack. That is not one PBI that is several PBIs because it

cannot be done in one sprint. Then It gets hard to communicate the progress and

keep a shared understanding of the PB.

Lets say it takes 6 sprints to do the rewrite. I would then have 6 PBIs in the

PB, because the PBI is too large. And to me that will also reduce transparency.

I think this is a hard subject for a PO.

 

And example could be that I want to rewrite an app from one old tech stack to
another modern tech stack. That is not one PBI that is several PBIs because it
cannot be done in one sprint. Then It gets hard to communicate the progress and
keep a shared understanding of the PB.

Correct, because that's only ever a secondary measure of progress. The primary measure is to have Done increments that provide empirical outcomes every Sprint. That's what stakeholders ought to care about. If that isn't an important consideration for the tech rewrite, you might wonder if the challenge is complex enough to demand a Scrum approach.

Makes sense

I know you said that you don't like to get caught in the names of the items in the Product Backlog.  However, there are ways to identify the relationships depending on the tool you use capabilities. I tend to find ways to group related items.  For example using a tag or label that can be searched.  Or linking all of the items that reflect work to a single item that states the overall problem.  This gives a way to easily see how much work is done and how much is left to be done.  

Using your app technology port example and assuming you are using Jira (because it is one of the most popular tools), you could create an Epic that represents the goal of porting the app to new technology stack.  Then you link all of the items that illustrate the actual work needed to accomplish that effort.  If you view the Epic you can get a pretty clear view of progress based upon current information.  This isn't an situation where you are creating multiple item types. It is way to organize your Product Backlog in a way that can be useful. 

To rephrase what @Ian said, the goal of each Sprint is to provide a valuable increment of work that meets the Definition of Done and satisfies the Sprint Goal.  That is what your stakeholders should be interested in knowing.  Value is the important part, not the time it is taking because it is quite possible that circumstances could change the original goal.  Help the stakeholders understand that you will only work on something until the actual need is fulfilled.  And the stakeholders are the ones that determine that need.