Late to this topic, so sorry if this was already discussed, but I didn't see this variation in the alternatives considered section of the proposal.
I agree with the sentiment that sugar would be nice for multi-dimensionality, but any sort of "a _ b" seems to invite confusion to me. Reading some of the user comments, it seems natural for people to express "x many things" using parenthesis. Obviously that's a bit overloaded with function calls and math operations. But since we're already used to array syntax using brackets [], why not just do a literal numeric prefix?
The examples then become:
// Nesting -
let fiveByFive: InlineArray<5, InlineArray<5, Int>> = .init(repeating: .init(repeating: 99))
let fiveByFive: 5[5[Int]] = .init(repeating: .init(repeating: 99))
// Inferring size from context
let fourBytes: _[Int8] = [1,2,3,4] // InlineArray<4, Int8>
// Inferring type from context
let fiveIntegers: 5[] = .init(repeating: 99) // InlineArray<5, Int>
let fiveDoubles = 5[](repeating: 1.23) // InlineArray<5, Double>
// Inferring size and type from context
let fourIntegers: _[] = [1,2,3,4] // InlineArray<4, Int>
Since the size is intended to be specified at compile-time, it must be an integer literal. And I don't think there's currently any legal way of using types inside of brackets [] other than for declaring an array type anyway, so doesn't seem like there should be any confusion to the compiler or the human.
Complex Types
Once you start getting into more verbose types, some people may desire parenthesizing the rhs of of to more explicitly call out the grouping... Imagine a fixed-size array of closures each returning a fixed-size array...
let fiveClosures: [5 of ((Int, String)->[2 of MyClass<String>])]
In this case, the brackets already give the separation, obviating that need:
let fiveClosures: 5[(Int, String)->2[MyClass<String>] ]
Mixing fixed and dynamic arrays
In the cases of mixing fixed size and dynamic arrays...
let fixedArrayOfDynamicArray: 5[[Int]]
let dynamicArrayOfFixedArray: [5[Int]]
versus
let fixedArrayOfDynamicArray: [5 of [Int]]
let dynamicArrayOfFixedArray: [[5 of Int]]
There's perhaps a danger of being too concise, but I feel like these are equally understandable (or not understandable, depending on your perspective 
)...
Additional feature?
Size inferred from context
There's also perhaps a minor benefit in the case of inferred sizes...
The example above showed using an underscore, following the example given in SE-0483:
let fourBytes: _[Int8] = [1,2,3,4]
let fourIntegers: _[] = [1,2,3,4]
Using this notation, we could perhaps drop the underscore and default to InlineArray for let cases.
let fourIntegers: [] = [1,2,3,4] // equivalent to InlineArray<4, Int>
But I think this is only advantageous if the "upgrade" cost of switching from InlineArray to Array at point of need is negligible, but I'll defer to someone more knowledgable in that area:
var dynamicIntegers: [Int] = fourIntegers // Create Array<Int> and assign contents of InlineArray<4, Int>
Arguably this automatic behavior could still be done with the of syntax, but because there's a strong correlation between of and InlineArray, I feel like it would be a much bigger surprise.
Crazy idea?
By extension, even in var cases:, perhaps the compiler could detect based on usage whether any dynamic features were actually used by the array and automatically switch to there's some things that could be done to dynamically determine whether InlineArray or Array is desirable?
func assignmentStaysAsInlineArray() {
let fourIntegers: [] = [1,2,3,4] // equivalent to InlineArray<4, Int>
var anotherFourIntegers: [] = fourIntegers // equivalent to InlineArray<4, Int> because size was never mutated
anotherFourIntegers[2] = 12
return
}
func assignmentUpgradesToArray() {
let fourIntegers: [] = [1,2,3,4] // equivalent to InlineArray<4, Int>
var anotherFourIntegers: [] = fourIntegers // upgrades to Array<Int> with content assigned from InlineArray<4, Int> because size is mutated
anotherFourIntegers.append(12)
return
}
Sounds hard to do to me, and not sure if it's worth the effort. But food for thought...