When 'python -c ${command}' is used and exception other than SyntaxError occurs, then line causing exception is not shown.

Problem seen in output of last 2 commands below:

$ cat /tmp/test1
1 /
$ cat /tmp/test2
1 / 0
$ cat /tmp/test3
a
$ python3.5 /tmp/test1
  File "/tmp/test1", line 1
    1 /
      ^
SyntaxError: invalid syntax
$ python3.5 /tmp/test2
Traceback (most recent call last):
  File "/tmp/test2", line 1, in <module>
    1 / 0
ZeroDivisionError: division by zero
$ python3.5 /tmp/test3
Traceback (most recent call last):
  File "/tmp/test3", line 1, in <module>
    a
NameError: name 'a' is not defined
$ python3.5 -c '1 /'
  File "<string>", line 1
    1 /
      ^
SyntaxError: invalid syntax
$ python3.5 -c '1 / 0'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ZeroDivisionError: division by zero
$ python3.5 -c 'a'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined

SyntaxError exceptions have a text attribute which contains the line where the error occurred. It's really a special case. For other exceptions, Python only knows that the error occurred in the file called "<string>".

Being able to display the line for any exception requires a complex development. I'm not interested to implement it, I don't think that it's very useful (compared to the time needed to develop it).

It should not be more complex to read a line from a command line argument than to read a line from a regular file.

Code entered with -c seems to be treated the same as code entered at the >>> prompt of the interactive interpreter.

>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

In both cases, the offending code is right there to be seen, so I can understand reluctance to echo it. For SyntaxErrors (and only them) echoing the code is needed to have something to point to.

Idle's Shell does what you want.
>>> 1/0
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    1/0
ZeroDivisionError: division by zero

Shell can do this because it has easy, platform-independent access to the tkinter Text widget storing and displaying previously entered code. I presume accessing a system-dependent console history buffer is much harder.

Where the difference really matters is when the error is in previously defined objects.

>>> def f():
...   return a

>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in f
NameError: name 'a' is not defined

versus (Shell)

>>> def f():
	return a

>>> f()
Traceback (most recent call last):
  File "<pyshell#16>", line 1, in <module>
    f()
  File "<pyshell#15>", line 2, in f
    return a
NameError: name 'a' is not defined

Argument of -c option can have multiple lines, while only 1 line can be directly entered in interactive interpreter.

python -c $'line1\nline2\nline3\nline4\n...'

One can paste multiple lines, comprising multiple statements, into the console interprer. (Shell only recognizes a single pasted statement.)
I agree, however, that it seems that Python could keep the split version of the input line for the purpose of tracebacks. I just tried

C:\Users\Terry>python -c "import sys; print(sys.argv)"
['-c']

I expected to see to see a list of 3 strings, not 1.

Arguments after argument of -c option are included in sys.argv:

$ python -c "import sys; print(sys.argv)" a b
['-c', 'a', 'b']

CC @pablogsal