Issue with Bera font and fontenc package

While @egreg diagnosed your problem in the comments, let me give you a workaround.

The Bera family of fonts is a clone of Bitstream Vera. So are the DejaVu fonts, which are in modern encodings, with extremely good coverage of Unicode. You can use those instead in either lualatex or xelatex.

\documentclass[varwidth, preview]{standalone}
\usepackage{fontspec}

\setmainfont{DejaVu Serif}
\defaultfontfeatures{Scale=MatchUppercase}
\setsansfont{DejaVu Sans}
\setmonofont{DejaVu Sans Mono}

\begin{document}
Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}

\textsf{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}

\texttt{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}
\end{document}

There are even two versions of a math font matching it, TeX Gyre DejaVu Math, which you can use in unicode-math. Unfortunately, it does not support sans-serif letters.

Since this sets the encoding to Unicode, copy-and-paste works. In fact, I used it to paste Erdős back into the document.

Compare the output with Bera, for which copying and pasting fails:

\documentclass[varwidth, preview]{standalone}
\usepackage[T1]{fontenc} % Redundant with bera.
\usepackage{textcomp}
\usepackage[utf8]{inputenc} % The default since 2018
\usepackage{bera}

\begin{document}
Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}

\textsf{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}

\texttt{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}
\end{document}

ETA:

@cfr points out that there are also dejavu and dejavu-otf packages. Loading dejavu instead of bera fixes your issue and also works in pdflatex, which this approach does not. See her answer for details. That said, do consider upgrading to the modern toolchain.

I wasn’t aware of dejavu-otf until she pointed it out to me, and it probably is a good idea to load it if its settings work for you, as she suggests. It’s likely to get updated if the commands you need to load the fonts ever change. And, if you install the package and update from time to time, you’re sure to have the latest version of the fonts.

If DejaVu Serif, Sans and Mono is an option, but you do not wish (or cannot) switch to another engine or just don't want to mess around with fontspec and extended compilation times, you can perfectly well use these fonts with pdfTeX instead.

\documentclass{amsart}

\usepackage{dejavu}
\usepackage[T1]{fontenc}

\begin{document}

Erd\H{o}s

\end{document}

Moreover, if you do want to use the opentype versions with XeTeX or LuaTeX, the recommended approach would be to use the relevant package:

\documentclass{amsart}

\usepackage{dejavu-otf}

\begin{document}

Erd\H{o}s

\end{document}

Do note, too, that, if you prefer, you can write Erdős in your source. This will work out-of-the box with XeTeX or LuaTeX. For pdfTeX, add

\usepackage[utf8]{inputenc}

If using this line or using XeTeX or LuaTeX, you must ensure that your .tex file is saved in UTF8 encoding. This is generally default for most editors nowadays, but there are some exceptions such as TeXShop.

When \usepackage{bera} is loaded, the output font encoding is automatically switched to T1, so loading \usepackage[T1]{fontenc} explicitly or not is irrelevant.

What is the problem? Let's look in the beraserif subpackage, to discover that the font family name is fve; therefore we look for t1fve.fd, that shows

\DeclareFontShape{T1}{fve}{m}{n}{
   <-> \fve@@Scale fver8t
}{}

OK, 8t, according to Karl Berry’s font name scheme means a T1 encoded font. However, we can examine it with vftovp fver8t to get output starting with

(VTITLE )
(FAMILY UNSPECIFIED)
(FACE F MRR)
(CODINGSCHEME EXTENDED TEX FONT ENCODING - LATIN)
(DESIGNSIZE R 10.0)
(COMMENT DESIGNSIZE IS IN POINTS)
(COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
(CHECKSUM O 10526223250)
(FONTDIMEN
   (SLANT R 0.0)
   (SPACE R 0.318)
   (STRETCH R 0.191)
   (SHRINK R 0.076)
   (XHEIGHT R 0.519)
   (QUAD R 1.0)
   (EXTRASPACE R 0.076)
   (PARAMETER D 8 R 0.729)
   (PARAMETER D 9 R 0.76)
   (PARAMETER D 10 R 0.928)
   (PARAMETER D 11 R 0.222)
   (PARAMETER D 12 R 0.928)
   (PARAMETER D 13 R 0.236)
   (PARAMETER D 14 R 0.636)
   (PARAMETER D 15 R 0.0)
   (PARAMETER D 16 R 1.2)
   )
(MAPFONT D 0
   (FONTNAME fver8r)
   (FONTCHECKSUM O 12607565666)
   (FONTAT R 1.0)
   (FONTDSIZE R 10.0)
   )

This is a virtual font, using the “raw” fver8r as base and remapping it. Now we can look into tables and discover that ő is assigned slot '245 (octal) in the T1 encoding; so let's look for O 256 in the human readable form of the virtual font:

(CHARACTER O 256
   (CHARWD R 0.602)
   (CHARHT R 0.7955)
   (CHARDP R 0.020499)
   (MAP
      (PUSH)
      (MOVEDOWN R -0.014)
      (MOVERIGHT R 0.051)
      (SETCHAR O 5)
      (POP)
      (SETCHAR C o)
      )
   )

Hey! It seems we found the problem! The “ő” glyph is composed of two glyphs from the raw font. Let's try the final experiment. Compile with pdftex the following test file

\pdfcompresslevel=0
\pdfobjcompresslevel=0
\nopagenumbers

\font\test=fver8t \test

\char'256

\bye

The first two instruction will make an almost human readable PDF file. At its start we find

3 0 obj
<<
/Length 74        
>>
stream
BT
/F52 9.9626 Tf 92.433 760.067 Td [(\005)]TJ -0.508 -0.14 Td [(o)]TJ
ET

endstream
endobj

that makes the problem clear: the PDF file encodes two glyphs. Why the accent appears after the “o” on copying and pasting depends on features and heuristics of PDF viewers.

If you look in the output of vftovp, you'll see that every accented character is realized in a similar way to ő.

With other fonts this doesn't happen. For instance, with \usepackage{dejavu} the font family name is DejaVuSerif-TLF and a similar trail following as before leads to examining the output of vftovp DejaVuSerif-tlf-t1 where we find

(CHARACTER O 256
   (CHARWD R 0.6021)
   (CHARHT R 0.7925)
   (CHARDP R 0.0137)
   (MAP
      (SETCHAR O 256)
      )
   )

No composed glyph! Hurray!