user45924: So int in Arduino is 2 bytes, which could technically hold up to a value of 65535. However, the MSB is used as a sign bit, so now we have -32,768 to 32,767. So it's a signed integer, easy stuff. While I was messing around with bitshifting I ran across something interesting. If I do the following code:
int a = 1023 << 6;  // 1023 = 0b0000001111111111
Serial.println(a, BIN);

it returns a ridiculous number, 11111111111111111111111111000000, which is 4 bytes. I know this is some error with bit shifting into the signed bit, because if I do
int a = 1023 << 5;  // equals 111111111100000 as expected

It works just fine. Question 1: What is happening here? Where is that number coming from?
So I got smart (so I thought) and was like okay, if I need more bytes, then I'll just use long. So I tried the following code:
long a = 1023 << 6;
Serial.println(a, BIN);

I figured I'd have 3 "extra" bytes to shift my number into. However, the same number is returned. Question 2: What is happening?
Question 3: What is the order of operations with bitshifting?
Wire.write(CMD_VDR | PD_NPD | voltageLevel >> 6);

This code I wrote produces the correct result. However, what is the order of operations? Is it just left to right? Putting voltageLevel >> 6 in parenthesis does not change the output. It's working fine but I want to know why!
Thanks!

user70020: 
So int in Arduino is 2 bytes

This is not true in the general case, for what it's worth. It is true of the AVR based Arduinos though, which I'll assume are in use below.
Strictly speaking, when you do int a = 1023 << 6; with a 16-bit integer, all bets are off, because you're already in undefined behaviour. 1023 is type int right hand side is expected to be of type int and trying to store something that won't actually fit in a signed integer is undefined.
But for the moment, lets just say it does roughly what you expect with the bit pattern, like it would for an unsigned type. You've produced the bit representation for a signed 16-bit integer with the value -64.
You're calling the println(int, int) here.
It's in turn calling println(long, int) here. It is only handling signedness for base 10. So, you are just forwarding your -64 value to printNumber here, which handle unsigned long values (which may have been prefixed by - for base 10).
So you are converting a -64 into an unsigned long. Conversion to unsigned types reduce modulo their maximum value plus 1.  The 32-bit unsigned long maximum is 0xFFFFFFFF, with one added you get 0x100000000. In other words, you're ultimately printing 0x100000000 - 64, which is the number you're seeing.
1023 << 5 does not overflow the 16-bit signed int. Does not result in a negative number (again if we're being charitable about undefined behavior) and so you see different result.

user7508: timemage provided an excellent answer to your first question (upvoted!).
Let me try to answer the subsequent ones:

long a = 1023 << 6;


Here you are evaluating 1023 << 6, then assigning the result to a
long. It is important to realize that the C++ rules for evaluating an
expression do not depend on what you are going to do later with the
result. Given that 1023 is an int constant, the expression has the
type int and is evaluated as such. The result is then undefined
behavior, which just happens, because you are unlucky, to give
the expected value, i.e. −64.
Assigning −64 to a long converts the type while preserving the value.
This is sign extension at work. As explained by timemage,
println(long, int) casts the value to unsigned long, hence the
result you see.

What is the order of operations
[in the expression CMD_VDR | PD_NPD | voltageLevel >> 6]?

The shift has higher precedence than the bitwise OR. The expression is
thus equivalent to
CMD_VDR | PD_NPD | (voltageLevel >> 6)

C.f. C++ Operator Precedence.

45924: <p>So <code>int</code> in Arduino is 2 bytes, which could technically hold up to a value of 65535. However, the MSB is used as a sign bit, so now we have -32,768 to 32,767. So it's a <em>signed integer</em>, easy stuff. While I was messing around with bitshifting I ran across something interesting. If I do the following code:</p>
<pre><code>int a = 1023 &lt;&lt; 6;  // 1023 = 0b0000001111111111
Serial.println(a, BIN);
</code></pre>
<p>it returns a ridiculous number, 11111111111111111111111111000000, which is 4 bytes. I know this is some error with bit shifting into the signed bit, because if I do</p>
<pre><code>int a = 1023 &lt;&lt; 5;  // equals 111111111100000 as expected
</code></pre>
<p>It works just fine. <strong>Question 1:</strong> What is happening here? Where is that number coming from?</p>
<p>So I got smart (so I thought) and was like okay, if I need more bytes, then I'll just use <code>long</code>. So I tried the following code:</p>
<pre><code>long a = 1023 &lt;&lt; 6;
Serial.println(a, BIN);
</code></pre>
<p>I figured I'd have 3 &quot;extra&quot; bytes to shift my number into. However, the same number is returned. <strong>Question 2:</strong> What is happening?</p>
<p><strong>Question 3:</strong> What is the order of operations with bitshifting?</p>
<pre><code>Wire.write(CMD_VDR | PD_NPD | voltageLevel &gt;&gt; 6);
</code></pre>
<p>This code I wrote produces the correct result. However, what is the order of operations? Is it just left to right? Putting <code>voltageLevel &gt;&gt; 6</code> in parenthesis does not change the output. <em>It's working fine but I want to know why!</em></p>
<p>Thanks!</p>
 70020: <blockquote>
<p>So <code>int</code> in Arduino is 2 bytes</p>
</blockquote>
<p>This is not true in the general case, for what it's worth. It is true of the AVR based Arduinos though, which I'll assume are in use below.</p>
<p>Strictly speaking, when you do <code>int a = 1023 &lt;&lt; 6;</code> with a 16-bit integer, all bets are off, because you're already in undefined behaviour. 1023 is type <code>int</code> right hand side is expected to be of type <code>int</code> and trying to store something that won't actually fit in a signed integer is undefined.</p>
<p>But for the moment, lets just say it does roughly what you expect with the bit pattern, like it would for an unsigned type. You've produced the bit representation for a signed 16-bit integer with the value -64.</p>
<p>You're calling the <code>println(int, int)</code> <a href="https://github.com/arduino/ArduinoCore-avr/blob/1.8.6/cores/arduino/Print.cpp#L77" rel="nofollow noreferrer">here</a>.
It's in turn calling <code>println(long, int)</code> <a href="https://github.com/arduino/ArduinoCore-avr/blob/1.8.6/cores/arduino/Print.cpp#L87-L101" rel="nofollow noreferrer">here</a>. It is only handling <code>signed</code>ness for base 10. So, you are just forwarding your -64 value to <code>printNumber</code> <a href="https://github.com/arduino/ArduinoCore-avr/blob/1.8.6/cores/arduino/Print.cpp#L203" rel="nofollow noreferrer">here</a>, which handle <code>unsigned long</code> values (which may have been prefixed by <code>-</code> for base 10).</p>
<p>So you are converting a -64 into an <code>unsigned long</code>. Conversion to unsigned types reduce modulo their maximum value plus 1.  The 32-bit <code>unsigned long</code> maximum is 0xFFFFFFFF, with one added you get 0x100000000. In other words, you're ultimately printing 0x100000000 - 64, which is the number you're seeing.</p>
<p><code>1023 &lt;&lt; 5</code> does not overflow the 16-bit signed int. Does not result in a negative number (again if we're being charitable about undefined behavior) and so you see different result.</p>
 7508: <p>timemage provided an excellent answer to your first question (upvoted!).
Let me try to answer the subsequent ones:</p>
<blockquote>
<pre class="lang-cpp prettyprint-override"><code>long a = 1023 &lt;&lt; 6;
</code></pre>
</blockquote>
<p>Here you are evaluating <code>1023 &lt;&lt; 6</code>, then assigning the result to a
<code>long</code>. It is important to realize that the C++ rules for evaluating an
expression do not depend on what you are going to do later with the
result. Given that <code>1023</code> is an <code>int</code> constant, the expression has the
type <code>int</code> and is evaluated as such. The result is then undefined
behavior, which just happens, because <a href="https://www.nayuki.io/page/undefined-behavior-in-c-and-cplusplus-programs" rel="nofollow noreferrer">you are unlucky</a>, to give
the expected value, i.e. −64.</p>
<p>Assigning −64 to a <code>long</code> converts the type while preserving the value.
This is <a href="https://en.wikipedia.org/wiki/Sign_extension" rel="nofollow noreferrer">sign extension</a> at work. As explained by timemage,
<code>println(long, int)</code> casts the value to <code>unsigned long</code>, hence the
result you see.</p>
<blockquote>
<p>What is the order of operations<br />
[in the expression <code>CMD_VDR | PD_NPD | voltageLevel &gt;&gt; 6</code>]?</p>
</blockquote>
<p>The shift has higher precedence than the bitwise OR. The expression is
thus equivalent to</p>
<pre class="lang-cpp prettyprint-override"><code>CMD_VDR | PD_NPD | (voltageLevel &gt;&gt; 6)
</code></pre>
<p>C.f. <a href="https://en.cppreference.com/w/cpp/language/operator_precedence" rel="nofollow noreferrer">C++ Operator Precedence</a>.</p>
