[Question]
  [
Write a [proper quine](https://codegolf.meta.stackexchange.com/q/4877/48934) whose every rotation is itself a proper quine.
For example, if your source code is `abcdef`, then:
* `abcdef` would output `abcdef`
* `bcdefa` would output `bcdefa`
* `cdefab` would output `cdefab`
* `defabc` would output `defabc`
* `efabcd` would output `efabcd`
* `fabcde` would output `fabcde`
A rotation ["is made by splitting a string into two pieces and reversing their order"](https://codegolf.stackexchange.com/q/5083/48934).
## Scoring
This is [code-golf](/questions/tagged/code-golf "show questions tagged 'code-golf'"). Shortest answer in bytes wins. [Standard loopholes](https://codegolf.meta.stackexchange.com/questions/1061/loopholes-that-are-forbidden-by-default) apply.
  
[Answer]
# [Alice](https://github.com/m-ender/alice), ~~138~~ ~~128~~ ~~74~~ 70 bytes
```
<pp&a0Ra*880R9Z640R8Z5e0R7*a70R6Z060R5Z9e0R4Z4R20R3*79Y3Zea0eZ1R51!Z73
```
Unfortunately, I had to fix a bug in the interpreter to make this work, so the current version doesn't work on TIO. [But you can try the 128-byte solution online.](https://tio.run/##S8zJTE79/9/CQkuvVDHRwMIoytLAxCzKwsAsNcrcwNA0yszA0lzL1MDMIMrEwNwkKMrYINU0yggkaGhgGmQYZWCQmKFWQKn@//8B "Alice – Try It Online")
You can use [this Python script](https://tio.run/##rVC7bsIwFJ3xV1wyNEkLwTwS0kisHTt0qeQKVYY4xCrY1rUR5etTOxRE9072Pa97bHN2rVbzrpMHo9GBPdsRaEtILRrAo/o0qHfID8lW1yKtyOAkXQvaCJXEAYpHEJ/iFLiFpoImO6F04iImAxTuiMrHZaZ3RHjcnGGijZvwvdyKiVROoPEygRluINiiNEPB6yQlJIywCpUy62qpbkSjESRIBcjVTiR0tPfh/U7fEAC1405q5b0B/BjLav3U36qxXHuBEt/Ok/fPu3pST8vmohiublEhFsCgL/xHesWi/rBVdA@GkMvMrRX@c1/43gpCfi3vGr/sMEq7riwfeUvLGeN0UbBnWghW0mnOlrSkrKAFZTldLt7Ygoqczangr2wW0CnN36aMUt62D@ZfQn4A) to verify that it works for all rotations, but again you'll have to run it locally against an up-to-date interpreter for the latest version. (Thanks to Jo King for providing that.)
## Explanation (for 74-byte solution)
[(Link to an explanation of the original 138-byte solution.)](https://codegolf.stackexchange.com/revisions/225545/1)
I was trying find a 2D language for [Razetime's bounty](https://codegolf.meta.stackexchange.com/a/22293/8478) where this might be possible and it turned out that it's actually very feasible in Alice. Unfortunately, the solution is a one-liner, not making much use of the two dimensions. That said, I'd be *very* impressed if this is possible with an actual 2D program (in any language), because almost every rotation would have one line broken into two pieces (one at the start and one at the end). I imagine a language would have to have a) multiple explicit entry points and b) a way to determine where on the grid an instruction pointer is to pick one that starts in a "safe" region of the grid. And then you'd still have to implement a quine for this that can work out what the actual current rotation is. So... uhhh...
### Printing the quine
Anyway, let's talk about this solution. I'm using grid manipulation (or self-modifying) command `p` to write our *actual* program into the grid. The main trick for letting me get below 100 bytes is to write that code *outside* the initial grid, specifically to the left of it (at negative **x** indices). This self-modification works regardless of the applied rotation (we'll get into why later), and prepends the following snippet to the code:
```
@o&J'h%p't"
```
This code will be executed from right to left. By the time we get here:
* there might be some rubbish left on the stack (depending on the rotation) - in one case, there might be an iterator in the queue (more about that later)
* in two cases (specifically those starting with a `p`) the first character of the original source code has been replaced with a null
* otherwise the original source always remains unchanged.
Before we get into how and why this self-modification works consistently, let's look at what the new code does.
```
"   Toggle string mode. While in string mode, Alice records every
    codepoint the IP travels over (with some caveats that don't
    matter). Since there's only one " on the grid, we'll record 
    every other cell, wrap around, and eventually hit " again.
    When we leave string mode again, all of the codepoints get 
    pushed to the stack. 
    There'll be a bunch of useless stuff at the bottom of the stack
    now but what's important is that the top 74 values are the
    original source code in reverse order.
    However, the leading 'p' might have been replaced with a null.
    Let's fix that.
t   Decrement.
'p% Modulo 112. Since 'p' is the biggest codepoint in the original
    source, this won't affect any value that corresponds to an 
    actual character. But if we had a 0, -1 % 112 becomes 111.
h   Increment. We've now mapped 0 to 112 and left all values from 1
    to 112 unchanged.
'J  Push 74, which happens to be the length of the source code.
&o  Pop and print that many characters from the top of the stack.
@   Terminate the program.
```
### Generating the printing code
On to the question of how we apply this source modification in the first place. Let's go back to half of the initial code:
```
<pp&ha0Na*880RaZ640R9Z5e0R8Z620R7Z060R6Z9e0R5Z4R20R4Z730R3Z060R2Zea0eZ1R51
```
We start on a `<` which makes the instruction pointer (IP) move west instead of east. The IP wraps around the edges, so we really start executing the code from the end and should once again read this code in reverse.
This makes use of `p`, which pops **y**, **x**, **v** and writes value/codepoint **v** to the location **(x, y)**. We use `ah&` to execute `p` 11 times, though the second `p` will add a 12th invocation. It's important for those to happen only in one place in the code for all rotations to work. All the other stuff before that just prepares the stack with inputs for these twelve invocations of `p`. Breaking the code down into `v, x, y` triples:
```
v     x   y
          ​1
5R1Z  e   0
aeZ   2R  0
60Z   3R  0
37Z   4R  0
2R4Z  5R  0
e9Z   6R  0
60Z   7R  0
26Z   8R  0
e5Z   9R  0
46Z   aR  0
88*   aN  0
```
Apart from pushing individual digits, there are only a few commands of note here. `e` pushes **-1**. `a` pushes **10**. `R` multiplies the top of the stack by **-1**. `N` computes the bitwise NOT. And then there's `Z`. You'll notice that most of them make use of it, the *zip* command. This command computes a bijection from a pair of integers to a single integer. The intended usage is to encode lists or other collections of numbers in a single number (to make it easier to store on the tape or the grid, for example), but it happens to be very useful for generating larger numbers in few characters. You can use [this Alice program](https://tio.run/##S8zJTE79/1/J0NhcX0FJISayTl/BHwgduPT@/wcA) to figure out which two numbers you need to get the desired result.
Also note that there's an additional **1** at the bottom of the stack. This is the only relevant input for the 12th invocation of `p`. Since this is the **y** this writes some garbage somewhere on the second line of the program, which we'll never encounter.
### Rotating the source
Finally, let's look at how various rotations of the source code behave. I'm going to shorten our "unrotated" source code to `<pp&haZYX` where `ZYX` represents the code that pushes all the constants. Let's go through the various possibilities:
```
pp&haZYX<
```
Here, we start on a `p`, which immediately reads three implicit zeros from the empty stack and replaces itself with a null. This is the reason any solution will *need* two `p`s, because the rotation which starts with `p` immediately loses it before it can do anything useful. For this particular rotation, we immediately run into another `p`, which does nothing and then `&haZYX` pushes a ton of random numbers we're never going to use. Finally `<` moves us left and we basically move through the exact same code as in the unrotated source, except we don't have the additional `p` any more (but that only wrote a useless character to the second line anyway).
```
p&haZYX<p
```
This one behaves a bit differently. The initial `p` still removes itself, so the behaviour isn't really different until we hit `<` move back and push all the constants. However, now when reach the left end of the code, our *actual* `p` hasn't been executed yet, so the quine-printing code doesn't exist yet. The IP wraps around and we finally modify the source with the `p` at the end. Then the IP moves through `ZYX` again, uselessly pushing the constants again. Finally, we end on `&ha` *just* before the `"`.
String mode works such that it makes use of the iterator queue when *leaving* string mode. So what this does is that we end up pushing all of the grid codepoints to the stack 11 times instead of once. But since we're only working with the top 74 stack values anyway, we don't care about the other 10 copies at all and this rotation ends up working as well.
Next:
```
&haZYX<pp
```
This is basically the same, except we don't replace a `p` with null (but do write a rubbish character to the second line).
And finally, putting the rotation anywhere inside the code that pushes constants:
```
YX<pp&haZ
```
This isn't fundamentally different, we just push a smaller amount of rubbish to the stack before hitting the `<` and executing the proper code.
[Answer]
# [Motorola MC14500B Machine Code](http://www.brouhaha.com/~eric/retrocomputing/motorola/mc14500b/mc14500b_icu_handbook.pdf), 1 byte
The 1 byte score is derived from two 4-bit instructions:
```
0000 0010
```
## Explanation
> 
> The Motorola MC145008 is a single chip, one-bit, static CMOS processor optimized for decision-oriented tasks. The processor is housed in a 16-pin package and features 16 four-bit instructions. The instructions perform logical operations on data appearing on a one-bit bidirectional data line and data in a one-bit accumulating Result Register within the ICU. All operations are performed at the bit level.
> 
> 
> 
The pins of the processor are numbered:
![Pin assignment](https://i.stack.imgur.com/SfCi8.png)
> 
> Instructions are presented to the chip on the 4 instruction pins, (`I0`, `I1`, `I2`, `I3`), and are latched into the Instruction Register, (IR), on the negative-going edge of X1.
> 
> 
> 
In layman's terms, pins 4 through 7, are used to present the Instruction Register with an instruction, but the bits are interpreted in the reverse order. For example, the instruction `0001` would have pin #7 in the high state and pins 6 through 4 in the low state.
> 
> The instructions, are decoded in the Control Logic (CTL), sending the appropriate logic commands to the LU. Further decoding is also performed in the CTL to send a number of output flags (`JMP`, `RTN`, `FLGO`, `FLGF`) to pins 9 through 12. These are used as external control signals and remain active for a full clock period after the negative-going edge of X1.
> 
> 
> 
Or, put simply, pins 9 through 12 are the output flags `FLGF`, `FLGO`, `RTN`, and `JMP`, respectively. Note that data is typically multiplexed to the `WRITE` pin (pin #2). The output flag pins are similar to other language's exit codes.
> 
> Each of the ICU's instructions execute in a single clock period.
> 
> 
> 
## Rotations
### Initial position
```
0000    NOPO
0010    LDC
```
The clock periods:
1. The `NOPO` instruction puts pin #10 (`FLGO`) in the high state. Before the next clock period, the output flag pins are put back into the low state.
2. The `LDC` instruction loads the complement of the Data Bus' value to the Result Register, without affecting the output flag pins.
So, during the program's two clock periods, the output flag pins have represented `0100 0000`, which, read in reverse (like the input pins), is `0000 0010`, or the original instructions.
### First rotation
```
0010    LDC
0000    NOPO
```
The clock periods:
1. The complement of the Data Bus is loaded to the Result Register, with no effect of the output flag pins.
2. Pin #10 in switched to the high state.
During these two clock periods, the output flag pins have represented `0000 0100`, which, when reversed, are the instructions `0010 0000`.
]