Right now, my best guess is:

111100001110000

with the following rule:

On lines which are not multiples of 4, convert any 01 substring to 00 and then remove the leading digit of the sequence. On lines which are multiples of 4, convert any 01 substring to 11 and then remove the trailing digit of the sequence.

This is less an answer, and more a collection of observations, because I'm not sure where to go.

First, as per some comments, I noticed that

The first sequence is binary for the decimal number 3141592, but I can't find any other references to pi in the sequence.

This sequence is also strange because the change from one line to the next can easily be altered by a change of view. For example, for most steps:

We can change 10 to 00 and then remove trailing digit

OR

We can change 01 to 00 and then remove leading digit

I also notice that the title generally applies no matter how we look at the sequence, but then:

From line 3 to line 4, the sequence definitely increases in value if the sequences have numerical values, even if there are padding zeroes on either end, and even if the binary is big-endian or little-endian, but the sequence length itself is the only thing that's shorter/smaller

I've tried a number of solutions that involve:

subtracting a binary number and then either left-bitshifting the answer or right-bitshifting the subtrahend to go again, with mixed success, but this still doesn't account for the change from line 3 to line 4.

Which leads me to ask myself:

Is there a way to interpret the sequences so that line 4 is distinctly smaller than line 3 in a non-length way?

But also:

What causes line 4 to increase instead of decrease like all other lines?
Is it that it is line 4 (which lead to the "every fourth line" argument)?
Is it that in the first two lines, a set of 1's disappears, but line 3 doesn't manage that, so line 4 is punished? Why aren't any subsequent lines punished, then?

Edit: With the new information, I have an algorithm which seems to produce the right results in all cases, but is surely not what the author intended.

My rule is:

Compare the 2nd bit with the 15th bit in the sequence.
If they are both zero:
A => Replace substring 01 with 11 and then remove last bit.
Otherwise:
B => Replace substring 10 with 00 and then remove last bit.

Following this rule, the first set of sequences follow

B B A B B B

to produce the given sequences, and the last sequence

has to be B, so gives 011000000100000

The second set of sequences follows the pattern

A B B A A A

to produce the given sequences, and the last sequence

is again a B, so gives 111111111100000

Right now, my best guess is:

111100001110000

with the following rule:

On lines which are not multiples of 4, convert any 01 substring to 00 and then remove the leading digit of the sequence. On lines which are multiples of 4, convert any 01 substring to 11 and then remove the trailing digit of the sequence.

This is less an answer, and more a collection of observations, because I'm not sure where to go.

First, as per some comments, I noticed that

The first sequence is binary for the decimal number 3141592, but I can't find any other references to pi in the sequence.

This sequence is also strange because the change from one line to the next can easily be altered by a change of view. For example, for most steps:

We can change 10 to 00 and then remove trailing digit

OR

We can change 01 to 00 and then remove leading digit

I also notice that the title generally applies no matter how we look at the sequence, but then:

From line 3 to line 4, the sequence definitely increases in value if the sequences have numerical values, even if there are padding zeroes on either end, and even if the binary is big-endian or little-endian, but the sequence length itself is the only thing that's shorter/smaller

I've tried a number of solutions that involve:

subtracting a binary number and then either left-bitshifting the answer or right-bitshifting the subtrahend to go again, with mixed success, but this still doesn't account for the change from line 3 to line 4.

Which leads me to ask myself:

Is there a way to interpret the sequences so that line 4 is distinctly smaller than line 3 in a non-length way?

But also:

What causes line 4 to increase instead of decrease like all other lines?
Is it that it is line 4 (which lead to the "every fourth line" argument)?
Is it that in the first two lines, a set of 1's disappears, but line 3 doesn't manage that, so line 4 is punished? Why aren't any subsequent lines punished, then?

Right now, my best guess is:

111100001110000

with the following rule:

On lines which are not multiples of 4, convert any 01 substring to 00 >! and then remove the leading digit of the sequence. On lines which are multiples of 4, convert any 01 substring to 11 and then remove the trailing digit of the sequence.

This is less an answer, and more a collection of observations, because I'm not sure where to go.

First, as per some comments, I noticed that

The first sequence is binary for the decimal number 3141592, but I can't find any other references to pi in the sequence.

This sequence is also strange because the change from one line to the next can easily be altered by a change of view. For example, for most steps:

We can change 10 to 00 and then remove trailing digit

OR

We can change 01 to 00 and then remove leading digit

I also notice that the title generally applies no matter how we look at the sequence, but then:

From line 3 to line 4, the sequence definitely increases in value if the >! sequences have numerical values, even if there are padding zeroes on either end, and even if the binary is big-endian or little-endian, but the sequence length itself is the only thing that's shorter/smaller

I've tried a number of solutions that involve:

subtracting a binary number and then either left-bitshifting the answer or right-bitshifting the subtrahend to go again, with mixed success, but this still doesn't account for the change from line 3 to line 4.

Which leads me to ask myself:

Is there a way to interpret the sequences so that line 4 is distinctly smaller than line 3 in a non-length way?

But also:

What causes line 4 to increase instead of decrease like all other lines?
Is it that it is line 4 (which lead to the "every fourth line" argument)? >! Is it that in the first two lines, a set of 1's disappears, but line 3 doesn't manage that, so line 4 is punished? Why aren't any subsequent lines punished, then?

Right now, my best guess is:

111100001110000

with the following rule:

On lines which are not multiples of 4, convert any 01 substring to 00 and then remove the leading digit of the sequence. On lines which are multiples of 4, convert any 01 substring to 11 and then remove the trailing digit of the sequence.

This is less an answer, and more a collection of observations, because I'm not sure where to go.

First, as per some comments, I noticed that

The first sequence is binary for the decimal number 3141592, but I can't find any other references to pi in the sequence.

This sequence is also strange because the change from one line to the next can easily be altered by a change of view. For example, for most steps:

We can change 10 to 00 and then remove trailing digit

OR

We can change 01 to 00 and then remove leading digit

I also notice that the title generally applies no matter how we look at the sequence, but then:

From line 3 to line 4, the sequence definitely increases in value if the sequences have numerical values, even if there are padding zeroes on either end, and even if the binary is big-endian or little-endian, but the sequence length itself is the only thing that's shorter/smaller

I've tried a number of solutions that involve:

subtracting a binary number and then either left-bitshifting the answer or right-bitshifting the subtrahend to go again, with mixed success, but this still doesn't account for the change from line 3 to line 4.

Which leads me to ask myself:

Is there a way to interpret the sequences so that line 4 is distinctly smaller than line 3 in a non-length way?

But also:

What causes line 4 to increase instead of decrease like all other lines?
Is it that it is line 4 (which lead to the "every fourth line" argument)?
Is it that in the first two lines, a set of 1's disappears, but line 3 doesn't manage that, so line 4 is punished? Why aren't any subsequent lines punished, then?