Do I really need the uprated 2.5A PSU?
The latest revision of the official power supply (5.1V/2.5A) is recommended for use with Pi 3. As the CPUs are a lot more powerful than previous Pi iterations, they can draw substantial peak currents that may overtax other power supplies. It is unlikely that you will experience issues with the previous official PSU (2A) unless you have additional high-current devices plugged into the USB ports.

What is the available USB port power?
The USB overcurrent switch now has a fixed, unalterable limit of 1.2A.

Why doesn't my Pi 3 ever go faster than 600MHz?
Undervoltage events force a reduction to idle clockspeeds for a substantial time-out period. If you rarely see 1.2GHz while running CPU-intensive applications, check to see if you're getting the small rainbow square in the top-right of the display, or if the PWR LED (red) is blinking.

Why is there an orange/yellow square in the top right of the display?
This indicates that the Pi 3 is throttling CPU speed due to thermal limitations. There is a graceful reduction in ARM clockspeeds if the SoC exceeds 80°C and during this time a yellow square icon is rendered on-screen. Idle clockspeeds (600MHz) are forced if the SoC hits 85°C. If this is an issue for your application, buy a heatsink - even a small one will likely prevent throttling.

My Pi 3 boots but there's no wlan0 device, why?
Use the latest release of Raspbian or an updated OS image for your distribution. You can boot recent Pi 2-compatible releases on a Pi 3, but without Pi 3-specific devicetree information the WiFi/BT chipset won't be recognised by the kernel.

My GPIO-connected UART device is broken on Pi 3, why?
The mini-uart is now routed to GPIO14/15 as the PL011 UART is now used for bluetooth communications. The mini-uart doesn't have a separate clock divisor and uses the core clock frequency. Changes in core clock (e.g. through throttling or idle/load frequency changes) will result in arbitrary modification of the effective baud rate. There's no easy way around this, but as a workaround there is a pi3-disable-bt devicetree overlay in latest rpi-update firmware which reverts this change.

I bought an ARMv8 computer, I want to run ARMv8 code RIGHT NOW!
The Cortex-A53 can run ARMv7 code just fine (in fact, substantially better than Pi 2 due to architectural improvements) and this is where we are staying in terms of supported userspace and kernel for the time being. If you want to roll your own OS/kernel, you can add arm_control=0x200 to /boot/config.txt to boot the cores in ARMv8 state.

BCM43438 supports FM reception, can I hack my Pi to attach an antenna?
No. The FMRX ball on BCM43438 is underneath the chip and surrounded by more important ones that needed to be routed out. PCB technology limits (no micro-vias, no via-in-pad) meant that we couldn't route this pin out at all.

Pithagoros wrote:Apart from clocking up to 1.2GHz and the other architectural improvements, is there a 64 bit Raspbian build in the pipeline, or other plans to take advantage of bigger words?

to quote
At launch, we are using the same 32-bit Raspbian userland that we use on other Raspberry Pi devices; over the next few months we will investigate whether there is value in moving to 64-bit mode.

How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

Just a suggestion though:
I do realise that it takes a lot of work to maintain an separate repository and the idea of having a separate armv7 repo was dropped for the same reason. But I think that it just might be worthwhile to have a separate 64bit repo due to the huge performance bump. But of course only if its financially viable.

Pithagoros wrote:Apart from clocking up to 1.2GHz and the other architectural improvements, is there a 64 bit Raspbian build in the pipeline, or other plans to take advantage of bigger words?

to quote
At launch, we are using the same 32-bit Raspbian userland that we use on other Raspberry Pi devices; over the next few months we will investigate whether there is value in moving to 64-bit mode.

ric96 wrote:I think that it just might be worthwhile to have a separate 64bit repo due to the huge performance bump.

For the most part you could probably use the Debian arm64 repos for all the apps instead of the Raspbian ones, then the RPF could add their own arm64 for the Pi specific stuff that is held on the raspberrypi.org servers. The main work would be building 64 bit image files. NOOBS could stay as it is, but perhaps detect that it is running on a 64 bit system and give the option of downloading 64 bit versions of the available OSen.