Here's an example:

---
C:\Sites>kramdown

This works: $$P(a,b)$$

This fails: $$P(a|b)$$

^Z
test!!
<p>This works: <script type="math/tex">P(a,b)</script></p>

<table>
  <tbody>
    <tr>
      <td>This fails: $$P(a</td>
      <td>b)$$</td>
    </tr>
  </tbody>
</table>
---

Kramdown.parse_inline_math doesn't seem to get called in the second case.

Date: 2012-06-02 06:20
Sender: Thomas Leitner

The problem with tables is that it uses a syntax that uses symbols
(i.e. `|`) distributed over the whole line whereas most other
block syntax uses symbols at the start of the line. This interferes
with the parsing logic (first block level elements, then span
level elements).

There are already some exceptions in the parser for tables, e.g.
for code spans. I will have a look at it.

Date: 2012-04-25 10:48
Sender: Tom Dong

A more tricky circumstance might be:

C:\Sites>kramdown
|$$P(a|b)$$|1
^Z
<table>
  <tbody>
    <tr>
      <td>$$P(a</td>
      <td>b)$$</td>
      <td>1</td>
    </tr>
  </tbody>
</table>

Date: 2012-04-25 10:44
Sender: Tom Dong

I think it might be a good idea to *require* table lines to start
with a '|' character, which also fixes this bug.

Requiring a '|' to lead a table line makes the intention of starting
a table element more explicit, consequently increases
readability.

Personally, I found it annoying to be forced to escape every
'|' in a paragraph, e.g. in emoticons like "-_-|||".

Maybe just change the 33rd line of \parser\kramdown\table.rb
from:
TABLE_PIPE_CHECK = /(?:\||.*?[^\\\n]\|)/
to:
TABLE_PIPE_CHECK = /(?:\|)/