user31947: The example is in here:
https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0
Actually, there are two outputs
DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and  RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]
The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.
There are two questions about this transaction.

How the coinbase could have more than 12.5 BTC?
What is the purpose of the RETURN PUSHDATA(36)(...), actually, in theory, this output can never be consumed by anyone, becuase there is no OP_CHECKSIG or similar OP at the end to return true in the Script stack.


user5406: As MCCCS said, the mining reward is composed of block subsidy and transaction fees.
The second output on the coinbase commits to the witness data in the block.
As you might know, the blockheader commits to transactions in the block via the Merkle root field. The Merkle root is produced by building a Merkle tree from the TXIDs (transaction identifiers) of all transactions. Since TXIDs do not commit to the witness data, the Merkle root alone would leave the witness data mutable.
Every block that includes any segwit transactions must therefore the Witness Commitment. The Witness Commitment takes the form of a 36-byte OP_RETURN output on  the coinbase transaction that has the prefix aa21a9ed followed by the 32-byte hash that is the Merkle root of the transactions WTXIDs (witness transaction identifiers). The WTXIDs are produced from the whole transaction, including the witness.

user38618: 
1) How the coinbase could have more than 12.5 BTC?

Because of transaction fees

2) What is the purpose of the RETURN PUSHDATA(36)(...),

The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.

user85140: 
2) What is the purpose of the RETURN PUSHDATA(36)(...), actually, in
  theory, this output can never be consumed by anyone, because there is
  no OP_CHECKSIG or similar OP at the end to return true in the Script
  stack.

From my understanding, this is mandatory in SegWit enabled blocks.
The second script (starting with OP_RETURN) provides the merkleroot of the witness tree. IIRC it was created this way to prevent a hard fork. Adding an extra field into the block header would defiantly require a hard fork, so the best alternative was to place the data somewhere already available in all current blocks. Since the OP_RETURN script will never be a valid output, it will simply be ignored.
Reference and more information: BIP141 Commitment structure and a similar question

31947: <p>The example is in here:
<a href="https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0" rel="nofollow noreferrer">https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0</a></p>
<p>Actually, there are two outputs
<code>DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and  RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]</code></p>
<p>The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.</p>
<p>There are two questions about this transaction.</p>
<ol>
<li>How the coinbase could have more than 12.5 BTC?</li>
<li>What is the purpose of the <code>RETURN PUSHDATA(36)(...)</code>, actually, in theory, this output can never be consumed by anyone, becuase there is no <code>OP_CHECKSIG</code> or similar OP at the end to return true in the Script stack.</li>
</ol>
 5406: <p>As MCCCS said, the mining reward is composed of block subsidy and transaction fees.</p>
<p>The second output on the coinbase commits to the witness data in the block.
As you might know, the blockheader commits to transactions in the block via the Merkle root field. The Merkle root is produced by building a Merkle tree from the TXIDs (transaction identifiers) of all transactions. Since TXIDs do not commit to the witness data, the Merkle root alone would leave the witness data mutable.</p>
<p>Every block that includes any segwit transactions must therefore the <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer"><em>Witness Commitment</em></a>. The Witness Commitment takes the form of a 36-byte <code>OP_RETURN</code> output on  the coinbase transaction that has the prefix <code>aa21a9ed</code> followed by the 32-byte hash that is the Merkle root of the transactions WTXIDs (witness transaction identifiers). The WTXIDs are produced from the whole transaction, including the witness.</p>
 38618: <blockquote>
  <p>1) How the coinbase could have more than 12.5 BTC?</p>
</blockquote>

<p>Because of transaction fees</p>

<blockquote>
  <p>2) What is the purpose of the RETURN PUSHDATA(36)(...),</p>
</blockquote>

<p>The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.</p>
 85140: <blockquote>
  <p>2) What is the purpose of the RETURN PUSHDATA(36)(...), actually, in
  theory, this output can never be consumed by anyone, because there is
  no OP_CHECKSIG or similar OP at the end to return true in the Script
  stack.</p>
</blockquote>

<p>From my understanding, this is mandatory in SegWit enabled blocks.</p>

<p>The second script (starting with <code>OP_RETURN</code>) provides the merkleroot of the witness tree. IIRC it was created this way to prevent a hard fork. Adding an extra field into the block header would defiantly require a hard fork, so the best alternative was to place the data somewhere already available in all current blocks. Since the <code>OP_RETURN</code> script will never be a valid output, it will simply be ignored.</p>

<p>Reference and more information: <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer">BIP141 Commitment structure</a> and <a href="https://bitcoin.stackexchange.com/a/74183/85140">a similar question</a></p>
